Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9907 - Some font's FONTBOUNDINGBOX correct.

Attached to Project: Rockbox
Opened by Yoshihisa Uchida (Uchida) - Saturday, 14 February 2009, 07:03 GMT+2
Last edited by Alexander Levin (fml2) - Saturday, 07 March 2009, 00:46 GMT+2
Task Type Patches
Category Font/charset
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

I corrected FONTBOUNDINGBOX because it was the small value of the follwing fonts.

05-Tiny.bdf
06-Tiny.bdf
08-Rockbox-Propfont.bdf
10-Artwiz-Snap.bdf
10-Nimbus.bdf
11-Nimbus.bdf
12-Nimbus.bdf
13-Nimbus.bdf
14-Nimbus.bdf
16-Jackash.bdf
18-Fixed-Bold.bdf
18-Fixed.bdf
19-Nimbus.bdf
This task depends upon

Closed by  Alexander Levin (fml2)
Saturday, 07 March 2009, 00:46 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  The problem described here was fixed in r20219. No more illegal memory accesses should ever happen.
Comment by Yoshihisa Uchida (Uchida) - Saturday, 14 February 2009, 07:05 GMT+2
Patch file is the follwoing.
   fonts.patch (5.5 KiB) 
 b/fonts/05-Tiny.bdf             |    2 +-
 b/fonts/06-Tiny.bdf             |    2 +-
 b/fonts/08-Rockbox-Propfont.bdf |    2 +-
 b/fonts/10-Artwiz-Snap.bdf      |    2 +-
 b/fonts/10-Nimbus.bdf           |    2 +-
 b/fonts/11-Nimbus.bdf           |    2 +-
 b/fonts/12-Nimbus.bdf           |    2 +-
 b/fonts/13-Nimbus.bdf           |    4 ++--
 b/fonts/14-Nimbus.bdf           |    2 +-
 b/fonts/16-Jackash.bdf          |    2 +-
 b/fonts/18-Fixed-Bold.bdf       |    2 +-
 b/fonts/18-Fixed.bdf            |    2 +-
 b/fonts/19-Nimbus.bdf           |    2 +-
 13 files changed, 14 insertions(+), 14 deletions(-)

Comment by Alexander Levin (fml2) - Monday, 16 February 2009, 21:45 GMT+2
IIUC you changed the font with field. But many fonts here are not fixed with but rather variable width. E.g. all Nimbus fonts. Hence they explicitly define glyph width for every glyph. Hence the font width info for the whole font doesn't really make any sense and can't be correct or not correct. This could make sense for fixed width fonts only if each glyph doesn't have the width definition.
Comment by Yoshihisa Uchida (Uchida) - Friday, 20 February 2009, 11:38 GMT+2
It is thought that there is no influence in the character displayed even if the value of fbbx in FONTBOUNDINGBOX changes.
Because only the value of fbbx in FONTBOUNDINGBOX is used to decide the maximum value of the width of the character by making fnt files (convbdf),
and the maximum value of the width of the character is adjusted by using the value of DWIDTH or BBX according to the width of an actual character.

When it is a setting of a current font, an illegal memory is accessed while making fnt files because the allocated memory size is small.

Comment by Alexander Levin (fml2) - Friday, 20 February 2009, 22:08 GMT+2
Ah, now I have understood what you were at. In the program there is a "safety buffer" to catch the cases where the font width is specified too low. I have come up with another solution. Since it's not specified that the font bounding box should be the MAX width, the program should be able to process files where it's set to, say, 2, but there are glyphs of width 20.

I changed the program so that if a greater glyph width is found (than what is specified in the font header), the font bitmap buffer is reallocated so that it can hold the font with its new width. Thus we'd be on the safe side even if we get a "bad" BDF file with a too low value of the font width in the header.

What do you think?

The program can be further simplified: the EXTRA safety buffer should not be needed anymore. But it can be removed later.
   fontgen.patch (5.3 KiB) 
 tools/convbdf.c |   56 ++++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 36 insertions(+), 20 deletions(-)

Comment by Alexander Levin (fml2) - Friday, 20 February 2009, 22:27 GMT+2
PS. A note for the reviewers: the EXTRA buffer made possible processing of the files modified by the OP's patch. But if a font is large enough (e.g. unifont) then the buffer allocation error would eventually become too large and the program would crash. My patch fixes this. Not, even 0 can be specified as the font width in the header. If each glyph's width is specified correctly everything should get processed just fine (with some warnings output to stderr).

Loading...