>> 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. > > This issue should be handled at compress time by choosing to compress by blocks of desired size. This way font layer doesn't need to care anymore. > 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. >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel