• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface → Font/charset
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Uchida - 2009-02-14
Last edited by fml2 - 2009-03-06

FS#9907 - Some font's FONTBOUNDINGBOX correct.

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


Closed by  fml2
2009-03-06 23:46
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

The problem described here was fixed in r20219. No more illegal memory accesses should ever happen.

Patch file is the follwoing.

fml2 commented on 2009-02-16 20:45

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.

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.

fml2 commented on 2009-02-20 21:08

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.

fml2 commented on 2009-02-20 21:27

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).


Available keyboard shortcuts


Task Details

Task Editing