| |||||||||||||
Rhaaa, yet another font format!Rhaaa, yet another font format!Posted Jun 25, 2009 9:00 UTC (Thu) by nim-nim (subscriber, #34454)Parent article: GRUB 2 becomes the default bootloader in Ubuntu 9.10
So they felt they needed to invent a new font format. Couldn't they really use one of the numerous existing ones? (restricting possibly to a specific profile with a profile checker).
They claim they want unicode support but specify ascii metadata.
And they've forgotten the third style attribute in modern (CSS/WPF) font classifications, width.
http://blogs.msdn.com/text/attachment/2249036.ashx
Now that Apple, Adobe and Microsoft finally agreed on a common universal font format (OpenType) do we actually need a new platform-specific application-specific one?
(Log in to post comments)
Rhaaa, yet another font format! Posted Jun 26, 2009 4:39 UTC (Fri) by colinb (guest, #59303) [Link] As the author of the graphical menu support in GRUB 2 and the creator of the new font format, I can defend the decision to create a new font format in a few ways. First, it was decided at the beginning of the graphical menu project that bitmap fonts should be used at first, and possibly down the road we could add support for vector (outline) fonts, and we would definitely need to depend on an external library for the more complex rendering of vector fonts. There has been discussion of using the FreeType library to provide support for OpenType, TrueType, and many other font formats. In my opinion, full vector font support would not be too difficult to add to GRUB. As for using an existing bitmap font format such as BDF of PCF, I seriously considered them but found them altogether unsatisfactory for our specific purpose. Here is my analysis of why another font format was needed. We also have discussed plans to add LZMA compression support to the font format, which would dramatically improve storage efficiency without impacting performance, by providing near-random access to characters of the font through compressing groups of characters together. As for the omission of the 'width' property of fonts, I simply considered that too unimportant of a detail, particularly in light of the fact that non-antialiased bitmap fonts were the only target of that font format, and none of the free fonts we tested with were provided in different widths. I do take your point about ASCII metadata for the fonts. True textual data such as the font name and family name should be Unicode strings, not ASCII.
Regards,
Correction to article: No font antialiasing or mouse support *yet* Posted Jun 26, 2009 4:49 UTC (Fri) by colinb (guest, #59303) [Link] Also, a quick correction to the article, which states: With respect to the technical qualities of GRUB 2, Rintel is mostly impressed about GRUB 2's modular architecture. He calls other features such as the graphics subsystem with mouse support capable of rendering antialiased Unicode glyphs "hardly things that would convince anyone to switch to GRUB 2". Actually, mouse support has not been added yet, though USB support has recently been added, and I'm about to commit the graphical menu branch to GRUB's mainline, so mouse support is not far off. Rendering antialiased text is not supported with the current bitmap-based fonts. If and when we add support for font rendering with FreeType, then we will have antialiased text rendering.
Regards,
Correction to article: No font antialiasing or mouse support *yet* Posted Nov 13, 2009 14:01 UTC (Fri) by evgenyz (guest, #61962) [Link]
So, why you then just don't make this bitmap font 8-bit/pixel? With such an alpha channel you can do anti-aliasing in compile (font conversion, huh) time and simply draw it in run time ("...making the code to read the font simple than we are with writing the font.").
Size? Just complete LZMA! It will be far more simple (and faster) to implement than OpenType rendering in run time.
|
|||||||||||||