New taller sysfont

[iPodVT]

I was concerned when I saw on the "Recent activity - Code" webpage  that the sysfont designation for ipodvideo/ipod6g has been changed to use a taller font.  Today I installed the latest dev build that includes that change and, sure as shootin', the bottom part of the text in theme's status bar is cut off.  Now I have to either add a font specification to my .sbs file as well as everywhere else where the sysfont was assumed to be static, or else I will have to reposition every one of the very tightly placed elements on all of my screens.

Which font was formerly the sysfont and which one is the new sysfont?

Was any consideration given to the likelihood of this predictable impact?

[iPodVT]

Is there a setting by which the user can specify a custom sysfont?  If not, might such a setting be added to Rockbox?  I'm not finding anything in the manual re such a setting, nor what the sysfont actually is.

[chris_s]

Which theme is this?

As far as I'm aware, this cannot be adjusted by the user. Not sure if there's a reason this couldn't be turned into a setting.

Have to admit, testing the patch, personally, I didn't look at custom themes using the default status bar. The default (and thus previous) sysfont is 08-Schumacher-Clean. Which has now been changed to 14-Rockbox-Mix on the Ipod video/6g.
The Eros Q was apparently already using that font, so presumably has trouble displaying any themes that expect the sysfont size to be 8, as well.

[speachy]

SYSFONT is compiled-in font of last resort.  It is limited to 250 glyphs, and really isn't intended to be _used_ by normal stuff at runtime due to it not having much language coverage.

The default statusbar is set to the same height as the SYSFONT, because SYSFONT is used to render stuff like the battery percentage or volume level.  That assumption needs to be broken, but at the same times, themes that don't include their own themed status bar shouldn't be making assumptions about how large the default status bar is.

In the short term the default sysfont size will probably be reverted while we try to figure out a better path forward.  But in the end, I don't expect we'll be able to avoid breaking themes that contain hardcoded assumptions about external assets.

[iPodVT]

Thanks very much for your reply.

Which theme is this?

Sorry - I left off the word "my" - it should have read "... the bottom part of the text in my theme's status bar is cut off."  I've been developing my theme for a few years - it's not yet ready for publication and might never be.  But even so, changing something as fundamental as the sysfont without advance notice is not what I would expect given the huge number of already published (and possibly affected) themes.

I fully acknowledge that the new sysfont is much more readable, so it is an improvement and I would like to incorporate it.  I guess that all font usage in all themes should explicitly specify a named font rather than making assumptions re sysfont if that is something that could get changed (again) in the future.

In comparing the default cabbiev2 theme on one iPod that uses the new dev build and new sysfont vs a slightly older cabbiev2 on another iPod using a recent dev build with the former sysfont, the height of the status bar appears to have been increased and the menus of long lists in the database and file browsers appear to have been slightly lowered, and yet those long lists still fit properly in the available vertical space, so that is good.  I do notice that the PLAY/PAUSE/STOP icons in cabbiev2's status bar are not properly placed vertically with the new sysfont dev build.

I don't think that adding/using/requiring a user specified sysfont setting is the right solution in this situation.  If the new sysfont is here to stay (and therefore might get changed again in the future), then my theme (as well as all others that are similarly affected) must be adjusted accordingly so as to not make assumptions re the amount of display space that 'sysfont' will use.  This brings up a few other questions:  does the new sysfont also use more horizontal space than the former sysfont?  Which font is used for displaying the database and file browsers' lists?  They don't appear to have changed (though I'm not confident re my perceptions of that), so I assume they're not using "sysfont".  Is there another generalized name (maybe "listfont"?) that is used for them?

[iPodVT]

I didn't see speachy's above reply until after I posted my reply that immediately followed it.

[speachy]

This brings up a few other questions:  does the new sysfont also use more horizontal space than the former sysfont?  Which font is used for displaying the database and file browsers' lists?  They don't appear to have changed (though I'm not confident re my perceptions of that), so I assume they're not using "sysfont".  Is there another generalized name (maybe "listfont"?) that is used for them?

Lists and other UI elements (that can contain translatable or user-supplied text) are displayed using the so-called "UI_FONT"

(The default UI_FONT typically varies based on the screen size and can be overridden by the theme)

[iPodVT]

Cool - thanks for the info.

[iPodVT]

I just now installed the dev build 3539dd5a70 update which reverts the sysfont - thanks.

Now (not at this moment... ;-) I need to go into my theme files and start adding font specifications so as to eliminate the assumptions I have been making re things like sysfont.  Thanks very much for bringing this 'better practice' to my attention.

Unrelated to this but brought to my attention by having updated two successive dev builds in fairly rapid succession, I am reminded of two minor Rockbox Utility issues that I've been meaning to report and will do so shortly on the Rockbox Utility forum.

[iPodVT]

I want to unequivocally apologize for my testy overreaction to the changed sysfont yesterday.  It (my overreaction) was inappropriate and uncalled for.  Going forward I will try my best to be more diplomatically collaborative.

As well, I don't want to stand in the way of progress, so if no one else is affected by or has complained about the change, please do whatever is in the best interest of Rockbox, not my little as yet personal/private theme (which I have already modified to use a specifically named font (08-Schumacher-Clean.fnt) rather than sysfont for text in my status bar).

I've said it before and I'll say it again:  I love Rockbox, and it keeps getting better and better.

[Frankenpod]

I just now installed the dev build 3539dd5a70 update which reverts the sysfont - thanks.

Now (not at this moment... ;-) I need to go into my theme files and start adding font specifications so as to eliminate the assumptions I have been making re things like sysfont.  Thanks very much for bringing this 'better practice' to my attention.

Unrelated to this but brought to my attention by having updated two successive dev builds in fairly rapid succession, I am reminded of two minor Rockbox Utility issues that I've been meaning to report and will do so shortly on the Rockbox Utility forum.

Pretty sure some of my themes used the default status bar, and made assumptions about its size.  Writing a custom status bar in full every time is just that much more effort, so sometimes would just use the default one. 

[speachy]

Pretty sure some of my themes used the default status bar, and made assumptions about its size.  Writing a custom status bar in full every time is just that much more effort, so sometimes would just use the default one.

In of itself this isn't a problem (and is something that was intentionally supported).  However, we were in a position where the same theme was being listed as "compatible" with players that use different-sized sysfonts (which means status bar size because the sysfont is used in the default status bar for numeric values), so a theme coded for one will not work correctly on the others.

There are still places in the codebase (mostly plugins and little-used per-target debug code) that are hardcoded to an 8px sysfont size.  Correcting this assumption has been ongoing for a _long_ time.

That said, user themes shouldn't be making explicit use of SYSFONT (ie font id 0) for anything. Even use of UIFONT (id 1) is probably questionable.

We haven't come up with a good way to detect these problems in an automated fashion.  Once we do, we'll revisit bumping the sysfont size on these players.

[iPodVT]

That said, user themes shouldn't be making explicit use of SYSFONT (ie font id 0) for anything. Even use of UIFONT (id 1) is probably questionable.

If themes were to stop using UIFONT, then what function would be served by the Font setting at Settings->Theme Settings->Font?

[iPodVT]

I assume that many themes already don't use UIFONT or use it only minimally, and I understand both the advantage and necessity of that.  I also expect that for many (probably most) users, creating and/or editing themes is not a realistic proposition, and therefore having some theme(s) available with which they could at least alter the font would seem to be desirable.  I can well imagine the conflicts that this raises for the devs in keeping things both flexible and robust.