grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Font antialiasing v2


From: Michal Suchanek
Subject: Re: [PATCH] Font antialiasing v2
Date: Mon, 5 Apr 2010 23:33:41 +0200

On 5 April 2010 07:50, Evgeny Kolesnikov <address@hidden> wrote:
> On Fri, 2010-04-02 at 22:23 +0200, Vladimir 'φ-coder/phcoder' Serbinenko

>> +#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).
>
>> 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.

There are only very few graphic characters that actually don't need
the antialiasing because they are completely square. Note, however,
that even square multiline characters in Chinese fonts can benefit
from antialiasing for purpose of line alignment so the only characters
that don't are a few box drawings. When the replacement character is a
symbol like question tag it can benefit from antialiasing as well.

It is not advised to draw multitude of line characters in graphics
mode, plain lines should be used instead so the performance of drawing
these characters is not critical to the point that an additional
feature should be added to the file format IMHO.

Thanks

Michal




reply via email to

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