Font antialiasing maximum size setting

…another outline font question. When a ‘fresh’ Risc OS is installed the default maximum size of the font that would be displayed antialiased is 36 according to the configuration settings. So when I use the swi “Font_Paint” to plot some text I can actually detect that setting to come into effect.

Can this value be changed from within an application, if yes, how ?

To read: https://www.riscosopen.org/wiki/documentation/show/Font_ReadFontMax

To set: https://www.riscosopen.org/wiki/documentation/show/Font_SetFontMax

I find all the font max settings are stuck back in the days of a 1MB Archimedes. Modern machines have obscene amounts of memory sitting around doing nothing (given the lack of disc caching), so the default font maxes should be at least increased to something more sensible.

I’m currently using:-

Cache bitmaps 144pt
Anti-alias    144pt
Sub pixel H    16pt
Sub pixel V    12pt
Initial       1024K
Max cache     4096K

I can’t get there! Configure won’t let me increase the initial fon’t cache above 1020K

I can’t get there! Configure won’t let me increase the initial fon’t cache above 1020K

I expect that the Configure front-end is also stuck in the past as Druck suggests about the default values.

Try the Configure command itself and see if that helps.

Configure won’t let me increase the initial fon’t cache above 1020K

The limiting factor is actually CMOS byte 134 (FontSize) which holds the initial size of the font cache in 4K units. It’s one byte, so the maximum value it can hold is 255×4K = 1020K.

Thanks all! @David: Yeah, I was thinking that, too. Another ancient thing is that IIRC the current setting of the next slot for an application is still at 640 KByte :-) …I can only guess keeping all of that is for compatibility for older machines…if not I would also propose to adjust most of those values to a more suitable setting for the new boards for the versions to be downloaded here…

Can this value be changed from within an application, if yes, how ?

It might be considered antisocial to change it (especially downwards) without clearly asking the user, though.

Configure won’t let me increase the initial font cache above 1020K

The limiting factor is actually CMOS byte 134 (FontSize) which holds the initial size of the font cache in 4K units. It’s one byte, so the maximum value it can hold is 255×4K = 1020K.

see DiscDev.Disc.RiscOS.Sources.SystemRes.Configure2.PlugIns.FontSetup.c.Settings

  Purpose:	Different versions of the Font Manager module place different
		interpretations upon the CMOS values for the configured font
		maximum size. For example, versions < 3.42
		multiply the stored value by 4 KB whereas versions >= 4.32
		will multiply it by 64 KB.
...


/* Font cache size is defined in multiples of n KB depending upon FontManager version */
  throw (rmversion (rmversion_RAM, "FontManager", &version));
  if (version >= 0x34200)
    fontstepsize = 64;
  else
    fontstepsize = 4;

  throw (numberrange_set_bounds (0x7, mainwindow_id, mainwindow_cacheinit, 0, 255*4, 4, 0));
  throw (numberrange_set_bounds (0x7, mainwindow_id, mainwindow_cachelimit, 0, 255*fontstepsize, fontstepsize, 0));

Font cache limit now max’s out at 16320K, it could be simple to do something to increase the Initial font cache size, if really necessary.

Perhaps the reading of all these limits could be changed so that they are interpreted according the amount of RAM discovered and they scale automatically?

Purpose: Different versions of the Font Manager module place different
interpretations upon the CMOS values for the configured font
maximum size. For example, versions < 3.42
multiply the stored value by 4 KB whereas versions >= 4.32
will multiply it by 64 KB.
…

That’s a typo on the version numbers.
The code is simply checking for >= 3.42 and applying the 64K step size or 4K otherwise

so the default font maxes should be at least increased to something more sensible.

Mine’s similar – but the caching and anti-alias stops at 64pt because I rarely need anything larger on-screen.
The subpix is 32pt in both directions.

which holds the initial size of the font cache in 4K units.

In case you don’t “read code”, as of the UTF capable FontManager, it’s in 64K units (because Asian fonts are big). The Configure widget is living in the past. ;-)

It might be considered antisocial to change it (especially downwards)

My Kana tutor changes it (up) as it uses large fonts in the window and that looks a bit rubbish without the anti-aliasing. The original settings are read, and restored on exit.
Given the amount of memory, I don’t see any reason for needing to change it down. It used to be a trick to gain some extra memory (nuke the font cache), but these days, no need.

Perhaps the reading of all these limits could be changed so that they are interpreted according the amount of RAM discovered and they scale automatically?

Or just bake in some bigger defaults for anything post IOMD.

One of the changes that I make when building my own ROM is to hardwire the Next slot to 4096K, because 640K (current default) dates back to the MEMC era.
It’s less of a problem now that our version of the OS is smart enough to allocate a slot large enough for the program that is being loaded, but still…. I at least know I can run the compiler in a TaskWindow. ;-)

That’s a typo on the version numbers.

Indeed, the description does not match the code.

In case you don’t “read code”, as of the UTF capable FontManager, it’s in 64K units

I’m well aware that FontMax (CMOS byte 200) has units of 64K. My comment related to FontSize (CMOS byte 134) which has units of 4K.

Just to be sure, I had a look at the source file David Pitt kindly pointed out. At lines 202-205 I found this:

  throw (numberrange_get_value (0, mainwindow_id, mainwindow_cacheinit, &fontsize));
  cmos_write (FontSize, fontsize / 4 );
  sprintf (string, "ChangeDynamicArea -FontSize %dK", fontsize);
  _swix (OS_CLI, _IN(0), string);

which does appear to suggest that the initial font size is saved to CMOS in units of 4K.

For the record, FontMax gets saved like this (lines 164-166):

  throw (numberrange_get_value (0, mainwindow_id, mainwindow_cachelimit, &fontmax));
  fontmax /= fontstepsize;
  cmos_write (FontMax, fontmax);

So FontMax – and only FontMax – uses 64K units from FontManager 3.42 (February 1999) onwards.

So FontMax – and only FontMax – uses 64K units

It does seem strange, but on the other hand, FontSize is the ‘initial’ setting, with FontManager using up to FontMax. So setting FontSize to 1020K and FontMax to 16MB should give you plenty of space to play around in.

Sure, it would have made sense if they were both the same (4K or 64K), but I rather suspect that FontMax is something that is handled by FontManager, while FontSize is handled by the kernel at boot … and while it is allocating memory, it doesn’t necessarily know what version (if any) of FontManager is present as this will happen prior to the module chain scan. So it stays stuck with 4K units.

It used to be in NewReset, it has moved to PMF.osinit: https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Kernel/s/PMF/osinit?rev=4.22.2.4#l180
(link to older CVS, as I’m using NetSurf to write this)

So I suspect that FontSize is a kernel thing, not a FontManager thing, hence the disparity.

I can’t get there! Configure won’t let me increase the initial font cache above 1020K

Sorry my mistake typing it in, it is 1020K.

Sure, it would have made sense if they were both the same (4K or 64K), but I rather suspect that FontMax is something that is handled by FontManager, while FontSize is handled by the kernel at boot … and while it is allocating memory, it doesn’t necessarily know what version (if any) of FontManager is present as this will happen prior to the module chain scan. So it stays stuck with 4K units.

Is there actually any negative effect of the initial font cache size being 1020K, or any lower value, if the system reaction to a lack of allocated space is to increase the allocation as required up to the defined maximum?

Is there actually any negative effect of the initial font cache size being 1020K, or any lower value, if the system reaction to a lack of allocated space is to increase the allocation as required up to the defined maximum?

This.

Just say FontSize at it’s max, set FontMax to whatever you want, and then forget about it.

I did wonder whether the final allocation for the cache would be contiguous and what effect that would have.