[Top][All Lists]

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

Re: fonts for gfxmenu, help needed

From: Michal Suchanek
Subject: Re: fonts for gfxmenu, help needed
Date: Sat, 28 Nov 2009 22:53:51 +0100

2009/11/28 Qianqian Fang <address@hidden>:
> Michal Suchanek wrote:
>> Thanks for these tips. I guess wider by one px is acceptable for an
>> alternate font, the fonts need not be displayed both at the same time.
>> I am not sure if lower quality glyphs of correct shape are preferred
>> over higher quality Chinese glyphs, though. I guess it would also
>> depend on reader preference but it would be nice to hear the opinion
>> of somebody familiar with Japanese.
> Using different fonts for different language makes life easier.

But slower. In grub loading a font and looking up glyphs in multiple
fonts is quite slow, at least in qemu where most people test the

>> For me the Song/Mincho variant fonts seem more readable at small
>> sizes. Although the serifs aren't clearly visible they often add
>> weight to the stroke ends and make them easier to recognize. However,
>> this may be matter of preference/reader familiarity with the
>> language/overall font quality/...
>> I think that there is not much need for smaller fonts than the default
>> 16px/12pt Unifont. It would be nice addition to have a font for
>> fine-print but I am personally more interested in larger font sizes
>> for captions or simple menus on high resolution screens.
>> In the larger sizes the difference between different font styles is
>> more visible.
> I misunderstood the call. You want to have fonts larger than 12pt,
> not smaller, as we usually concern. That's fine, actually that is
> a lot easier to handle.
> I don't know what sizes you prefer, you can find bitmap resources
> at typical sizes at 24px/32px/48px. Indeed, using freetype/autohint,
> the rasterization of the popular CJK fonts may entirely usable
> at these sizes.
> In the following links, I experimented to hint/instruct/rasterize
> the common CJK fonts, and I think the results are quite usable:
> Hei-style:
>  WQY Micro address@hidden:
>  WQY Micro address@hidden:
> Song-style:
>  Japanese address@hidden (efont f24):
>  Chinese address@hidden (uming):
> Except the efont 24px, all screenshots were made by rasterizing
> vector fonts with freetype2 with autohints. Here are the steps
> to reproduce:
> 1. open a TTF/TTC files in fontconfig, navigate to CJK zone (U4E00-U9FCB)

Am I missing something? For me fontconfig was always a commandline
tool. I do use some charmap tools but onen of them comes with

> 2. select tens to hundreds of glyphs, select menu Hint\Autohint
> 3. then, goto menu Element\Font Info...\PS Private, hit Add and add
>  multiple PS hints, include StdHW and StdVW, use the guessed values
> 4. select menu Hint\AutoInstruct

I wonder if this is reproducible with grub-mkfont.

Also is autohinting free enough to be enabled in Debian and other
distribution packages? I don't recall the exact details of the patent
issues with different font rendering methods.

> 5. select menu Element\Bitmap Strikes Available\, type whatever
>  pixel sizes you want in the 3rd box, check freetype, and click ok
> 6. now from menu View, select the strike you just generated
> As I mentioned earlier, if you want to produce Japanese Hei-style
> Kanji bitmaps, you can apply the above procedures to
> DroidSansJapanese. And of course, the bigger the size, the better the
> results.

I am not sure this is optimal method of rasterizing fonts. Perhaps
grub should be improved to handle vector graphics or at least fonts
rasterized into greyscale.

The uming_32px contains pretty large and mostly nice glyphs but they
are still clearly pixelated, even at this size.

Given the 1-bit bitmap limitation most glyphs look pretty good but the
灱 glyph just above the UmingCN title in the taskbar is particularly
ugly. Is this an expected limitation of this rendering method that
some glyphs simply turn out ugly or is this a bug in the font?



reply via email to

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