grub-devel
[Top][All Lists]
Advanced

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

Re: fonts for gfxmenu, help needed


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: fonts for gfxmenu, help needed
Date: Wed, 25 Nov 2009 11:32:27 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

Michal Suchanek wrote:
> 2009/11/25 Robert Millan <address@hidden>:
>   
>> On Tue, Nov 24, 2009 at 08:43:30PM +0100, Vladimir 'φ-coder/phcoder' 
>> Serbinenko wrote:
>>     
>>> I identified number of fonts as one of the reason of gfxmenu needing
>>> important amount of time to load. I prefer to have few nice looking free
>>> fonts with reasonable unicode coverage (we'll need it because of
>>> gettext) and load only ones really needed
>>> [...]
>>>       
>>>> I think that true bitmap fonts will look much, much better than
>>>> converted outline fonts, but perhaps if we added an 8-bit alpha channel
>>>> to the font format and grub-mkfont could do anti-aliasing during the
>>>> conversion process; then I think we could make use of all the free
>>>> outline fonts
>>>>         
>>> I'm ok wth doing any kind of preprocessing in grub-mkfont but grub2 has
>>> to remain simple in order to ensure reasonable performance even on slow
>>> system (curren't it's not the case and more work is needed for
>>> optimising it)
>>>       
>> I understand there's a lot of room for improvement, but it'd be interesting 
>> to
>> start providing a basic set of fonts so that we get the ball rolling and
>> theme authors can beging doing their artist work.
>>
>> Has someone obtained a working multi-size setup with grub-mkfont + unifont?
>> Currently I just know that the default ascii.pf2 works (but doesn't have any
>> single-size theme that would play well with it).
>>
>>     
>
> As I said that's pretty much impossible.
>
> unifont.ttf is just the bitmap squares recorded as outline, and even
> if you generate multiple sizes of bitmaps from that (and most of these
> are bound to be ugly bordering on useless) you still get only a single
> face which would not be acceptable for most theme authors.
>
> I would suggest looking at the bitmap fonts which used to be installed
> with X. They provide bitmaps in multiple sizes for multiple languages
> although the unicode coverage is much poorer than with unifont.
>
> Other thing we might try is scaling the font in grub itself. This is
> poor typography because proper scalable fonts are adjusted for
> different sizes, the outlines aren't simply scaled.
>   
Your statements are contradictory. First you say that scaling is bad and
shouldn't be used in grub-mkfont but then you tell to use the same
approach in grub.
The best way to choose between pre-scaling and scaling in grub is
benchmarking. Multiple fonts take longer to load but scaling even with
caching is likely to cause more performance hit.
How much fonts does an author need? We need either decrease number of
fonts simultaneously used or have faster font loader (both in preference).
As Robert said most important is to get things going and theme creators
can use other free fonts as well
>
> Note that with truetype fonts most fonts (besides the crappy
> English-only fonts) specialize on a family of languages that use the
> same writing system and the glyphs for other writing systems tend to
> be poorly drawn or non-existent.
>
> This is understandable as no font author can possibly know how the
> glyphs for all the various languages fit together. This also means
> that
>
>  - you typically have to install fonts specifically for language(s)
> you intend to use
>
>  - glyph fallback is integral part of any decent font system. Some try
> to determine the nearest matching font automatically with varying
> success, in some systems you can specify different fonts for different
> unicode ranges (which are then scaled to fit together).
>   
We have fallback system but again it would mean more fonts to load.
Perhaps we can use unifont as fallback (this way scaling artifacts are
less of the problem as user usually wouldn't have symbols outside of
normal coverage)
>  - there is a problem with Simplified Chinese/Traditional
> Chinese/Japanese. Some of the glyphs used by these writing systems
> have the same unicode codepoint but are slightly different in each. To
> get these rendered correctly you need special font for each. Blame the
> Unicode people.
>
>   
Let's not get into Unihan flamewar. There are other problems with other
languages which are more serious. Here are few of them:
1) combining diacritics.
2) ligatures. Important for indic languages
3) context variants. Important for Arabic writing system.
4) bidi. Important for Hebrew and Arabic writing system.

Generally current gfxterm is pretty much unsuited for any of these 4
problems. And gotoxy is pretty ambiguous in bidi context
Few useful links:
http://en.wikipedia.org/wiki/Help:Multilingual_support
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Unicode/Test/arabe

> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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