Re: [PATCH] Font antialiasing v2

[Michal Suchanek]

2010/4/9 Colin D Bennett <address@hidden>:
> 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.

Isn't gzip already compressed in fixed sized blocks?

I mean what you want is gzip random block access rather than stream
access, and it's been already done, at least in Linux cloop.

It is also general enough that it could be used for other files, not
only fonts and can work separate of the font system.

Thanks

Michal