Re: [PATCH] Font antialiasing v2

[Colin D Bennett <colin@gibibit.com>]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Mon, 12 Apr 2010 09:31:56 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:

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

But can you randomly seek to an block transparently and read it that
way?

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]