grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Font antialiasing v2


From: Colin D Bennett
Subject: Re: [PATCH] Font antialiasing v2
Date: Mon, 12 Apr 2010 07:24:09 -0700

On Mon, 12 Apr 2010 09:31:56 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> 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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]