themes not working because of missing fonts

[sorinake]

Here is the story.

Someone uses the rockbox utility to give a try to rockbox on its new toy. After successfully installing it on the device, goes the extra mile and downloads a theme without paying attention to the fine print listing the fonts that were required but not allowed to be packaged on the actual theme file. The surprise is that the theme fails to load, there is no warning/error message of any sort. Someone may think the theme is faulty and goes to the next one. Eventually s/he may find an old one that works, ignoring some of the new themes.

I am looking for a proactive approach as opposed to an reactive one (tell the user it has to do something, don't let him trying to figure out why the theme is not working). For "challenged" users it may be difficult to go the extra mile to find/get the entire font pack and select the few required by the theme.

Some of my suggestions are:
1. The old themes that managed to be posted with the fonts included have an advantage over the new themes. The existing zip files should probably be checked the same as the new submissions
2. Have some sort of a warning when a theme does not find its fonts as opposed to just display the default rockbox screen. That would give the user a chance to review the requirements before deciding the theme is bad.
3. Any other thing that you may think of making the experience better. I enjoy rockbox a lot and the story above happened to me trying the cassette theme for sansa fuze, being used to the old way of just loading a theme with all that was required included and not having a problem. It took me a while to figure out I was missing a font (I know I shoulda read the description carefully but I did not).

Many thanks to the rockbox community.

[bluebrother]

Someone uses the rockbox utility to give a try to rockbox on its new toy. After successfully installing it on the device, goes the extra mile and downloads a theme without paying attention to the fine print listing the fonts that were required but not allowed to be packaged on the actual theme file. The surprise is that the theme fails to load, there is no warning/error message of any sort.

That person however is pretty likely to have used the "Full Installation" option in Rockbox Utility which does install the fonts. So while the described scenario is possible I don't think it's likely to happen often for "normal" users.

1. The old themes that managed to be posted with the fonts included have an advantage over the new themes. The existing zip files should probably be checked the same as the new submissions

Hmm? As far as I know checkwps is run regularly on all themes on themes.rockbox.org

2. Have some sort of a warning when a theme does not find its fonts as opposed to just display the default rockbox screen. That would give the user a chance to review the requirements before deciding the theme is bad.

I'm not aware of such a behaviour. Rockbox will show the builtin theme if the theme (which means wps, sbs, and other screens) loaded has errors. However, this does not include a missing font -- you're free to use a different font for any theme if you want to (which obviously doesn't mean that the theme will then look as expected)

[[Saint]]

1. The old themes that managed to be posted with the fonts included have an advantage over the new themes. The existing zip files should probably be checked the same as the new submissions

Hmm? As far as I know checkwps is run regularly on all themes on themes.rockbox.org

I'm not sure this is the case at all...as soon as the theme is on the theme site, it doesn't ever need to be checked again...but that's besides the point.

It *was* possible to upload a theme with fonts from the theme pack, but then checkwps was set to warn on this and wouldn't let the upload pass, however I think that removing the included fonts from previously uploaded themes is a bit out of the scope of this tool.

There's nothing stopping users from including fonts that are named differently from those in the font pack, and there's pretty much nothing that can be done about that except banning the .fnt extension altogether...which would *suck* as most of my themes include fonts edited by myself and not available via the font pack.

I definitely don't think that users should be including the fonts from the font pack, as then they could be potentially downgrading their fonts every time they installed a theme....though I don't think that is *too* much of an issue presently...as despite it claiming it's built daily, the font pack appears to be over 2 years old.


[St.]

[Llorean]

Hmm? As far as I know checkwps is run regularly on all themes on themes.rockbox.org

I'm not sure this is the case at all...as soon as the theme is on the theme site, it doesn't ever need to be checked again...but that's besides the point.

If it didn't need to be checked again, how would the "Works with current version" possibly be even remotely reliable? They're rechecked to verify that they're still valid.

[sorinake]

On sansa fuze v2, I loaded the theme retroTape (http://themes.rockbox.org/index.php?themeid=866&target=sansafuzev2)
without the font "10-Nimbus.fnt" the wps reverts to the default one without warning ( see first attachment FuzeRetroCassete1.PNG) putting the font manually wps displays fine (see second attachment FuzeRetroCassete2.PNG)
If I did not know hou to read a wps I would have flagged the theme as not working.

 It may be a problem only with fonts loaded like this:
   %Fl(2,10-Nimbus.fnt)
 
Also if you look at the contents for the ART theme for sansa E200, it includes a font that is part of the font pack
  .rockbox/fonts/15-Adobe-Helvetica.fnt
link: http://themes.rockbox.org/index.php?themeid=425&target=sansae200

[[Saint]]

If it didn't need to be checked again, how would the "Works with current version" possibly be even remotely reliable? They're rechecked to verify that they're still valid.

Yes, yes...quite right.

Despite the fact that it's checkwps...I wasn't thinking about skin syntax changing for some reason.

I think checkwps won't let new themes through with fonts that are included in the theme pack, but I don't think it invalidates existing themes that contained the fonts before this sanity check was added, which is fairly sensible as there is a chance that the author could have modified the font and kept the original naming (I'm not sure exactly how likely that would be, but it's a possibility).

EDIT:

And yes, a theme will fall back to the failsafe if it can't find a font it needs to display a skin correctly, this isn't the most graceful behaviour I'll admit but it is a lot better than the way it used to handle this before the failsafe was added.
The failsafe theme is pretty much the user indication that "something went wrong with this theme", a nice little splash explaining exactly *what* went wrong probably wouldn't be a bad idea though.

EDIT 2: "Why this can happen..."

There's a few ways a viewport can be told to use a font.

~X,X,X,X,0) <-- Always use sysfont
~X,X,X,X,1) <-- Always use userfont

There's also

%Fl(2~9,fontname.fnt) <-- Load this specific font with this identifier
~X,X,X,X,2~9)  <--Display this specific font

This latter way will fail if it cannot load (and then cannot display) the additional userfont requested.


[St.]