I'd like to hear your opinion about the problem described in FS#9931.
In a few words, the problem is the following: a font has the metrics
"ascent" (how many pixels it goes above the base line) and "descent"
(the same, but below the base line). Rockbox considers the sum of these
two numbers the font height. This is the number that is in the beginning
of the name of the font. This is also the height of the cursor, if it's
set to "bar".
But there are some fonts that contain glyphs that go above the font's
ascent or below the font's descent.
This leads to unpleasant results where glyphs are displayed with some
unrelated "noise" (see pictures in FS#9931).
We had a discussion about it in IRC on 1-st of March, starting at about
linuxstb proposed five possible actions
1) Reject the font;
2) Reject the glyph;
3) Clip the glyph;
4) Increase the font height;
5) Rewrite the Rockbox font rendering and scrolling code
I think, the options 1 and 2 are too strict, and 5 is not feasible.
And llorean, at about 20:10, proposed to introduce a leading and to clip
above/below that. This is a combination of the options 3 and 4.
So my plan is as follows: I'll change the convbdf utility so that it
will have command line parameter for ascent/descent "stretchability" or
"tolerance". Before the font is generated, all glyphs will be analyzed
and the max values for glyph ascent/descent will be found. If they don't
go beyond the font's values then everything is fine. Otherwise the
font's ascent/descent values will be increased but no more than
specified by the new parameters. Parts of the glyphs that go beyond the
newly computed ascent/descent will be clipped, i.e. those parts won't be
generated in the .fnt file, and a warning message issued.
It will be possible to specify the amount for e.g. ascent to grow in
absolute pixels (nn), in % of the original value (nn%) and as a "must!"
value (nn!). The latter directly sets the ascent to the given value.
There will be separate parameters for ascent and descent. The default
value for the parameters will be 20%.
The advantage of this approach is that we try our best to use as many
fonts as possible and to show as many glyphs as possible in them. The
"too big" glyphs are a minority I think.
The drawback is that the generated font won't be the size it claims to
be. I.e. the result for the font "20-xyz" could have the height of 25.
What do you think? If there will be no objections, I'll implement it
Received on 2009-03-03