On Fri, 09 Apr 2010 19:54:07 +0200 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote:
> Evgeny Kolesnikov wrote: > > On Fri, 2010-04-02 at 22:23 +0200, Vladimir 'φ-coder/phcoder' > > Serbinenko wrote: > > > >> +#define FONT_FORMAT_STORAGE_PACK_MASK 0x0F > >> +#define FONT_FORMAT_STORAGE_PACKED 1 > >> +#define FONT_FORMAT_STORAGE_DEPTH_MASK 0xF0 > >> +#define FONT_FORMAT_STORAGE_1BIT 0 > >> +#define FONT_FORMAT_STORAGE_8BIT_GRAY 32 > >> Using entire byte for this is quite a waste. It's better to use 2 > >> or 3 last bit as STORAGE_FORMAT > > > > This byte is already wasted with packed/unpacked bit. > > 3 bits actually, others as reserved. And I used reserved ones. > > See http://grub.gibibit.com/New_font_format (PFF2 spec, CHIX, item > > 2). > > > > > Well "current" doesn't mean "best possible". I want to know motivation > behind this packed/unpacked bit. Certainly I don't claim that PFF2 is the best possible. It was just a first attempt that should be adapted and improved. Having storage flags for each character may or may not be helpful (we could easily require entire fonts to be either compressed or uncompressed), but that is just how it was initially specified. I will explain below the motivation behind the idea of "compressed character blocks". > Mixing compression and font engine will make the code more complex and > bug prone. It's better to put compression layer below the font and > make font subsystem unaware of it. The only exception is if > compression takes advantage of knowing font structures. My aim was to make it more practical to have full Unicode fonts of a decent size. Compressing the font would greatly decrease the disk space required, but if the entire font file was compressed using, for instance, GZip, then (generally speaking) the entire file would have to be decompressed to use the font. This would probably make it far too slow to display the GRUB menu when a few fonts were loaded. In my thoughts on font compression, there are a couple of opposing factors: - Compressing too little data produces poorer compression since there is less redundancy to eliminate. Consider the extreme case of compressing each glyph by itself with GZip. - Compressing too much data means that more time is spent decompressing glyphs at runtime that will not be used (in general, a small fraction a Unicode font would be used at once in GRUB). Consider the extreme case of compressing the entire font as a single unit with GZip. By compressing blocks of characters, where each block contains a number of characters that represents a compromise between too little data for good compression on disk and too much data for wasted time decompressing unused glyphs, good compression and good runtime performance can be attained. > >> Also I doubt usefulness of a font in which only some glyphs are > >> anti-aliased. Perhaps we could move antialiasing flags to file > >> header and shave off few bytes? > > > > Yes this makes sense. I.e. substitution glyph for unknown symbol > > have no AA. Also frames and other geometry can benefit from this. > > Anyway this byte is already wasted in original spec. > > > We can change the spec and make pff3. Also notice I didn't oppose to > glyph in memory having this info, only on disk > > Moreover I thinking about transparent gz or xz reader for font > > file. This will drastically reduce the size. > > > > > You can already gz it. How does this perform on full Unicode fonts? When 4 fonts are loaded? On low-end hardware (e.g., 800 MHz VIA C3, Intel Atom, etc.)? Regards, Colin
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel