Re: [PATCH] Font antialiasing v2

[Colin D Bennett]

On Fri, 09 Apr 2010 19:54:07 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> 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