Re: fonts for gfxmenu, help needed

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

hi list

My friend brought me attention to this thread, and
I am very glad to see a better CJK support is now
on the agenda of grub. As a Chinese font developer,
I am willing to help, share information or build
fonts for this specific need.

I wasn't really following how fonts were used in grub,
and still had the (wrong) impression that only 256
glyphs are allowed for each file. After opening the
overlay_2009-07-19 tarball, I saw large files such as
unifont are included, so, I guess now grub is able
to handle the full unicode (or BMP) fonts including
CJK ones, is this correct? do they have to be bitmaps?

If the answers to my above questions are "yes", then
I think you may consider a customized version
of "WenQuanYi Bitmap Song" [1], which is a multi-strike
bitmap font containing >27000 Chinese Han glyphs
at 9pt,10pt,10.5pt,11pt and 12pt sizes. The Latin
part of this font are not "monospaced", but we
can either merge it with other mono Latin fonts
(GPL compatible), or use fallback to get around it.

I saw you already have the later version of
GNU Unifont installed, if that's the case, then
you can skip the 12pt of WenQuanYi Bitmap Song,
because most of the CJK glyphs in Unifont 5.1
were ported from WQY's bitmap font last year by
Paul Hardy [2].

About format, I don't know if you can use ttf
file, or SFNT ttf file (with only embedded bitmaps).
WQY Bitmap Song has an SFNT TTF version [3]. It appears
that freetype2 works fine with it, but fontconfig
has difficulties. Using SFNT TTF, the uncompressed
font size is about 3M (with 9,10,11,12pt),which
is fairly lightweight.

If grub happens to be able to process vector
ttf fonts, I would recommend DroidSansFallback [4]
or the derived WenQuanYi Micro Hei [5]. They both
covers a huge span of languages, and the second one
have a lot more CJK glyphs and both proportional
and monospaced species.

Please let me know if you have any further comments,

Qianqian


[1] http://wenq.org/enindex.cgi?BitmapSong_en
[2] http://unifoundry.com/unifont.html
[3] http://sourceforge.net/projects/wqy/files/wqy-bitmapfont-pkgsrc/0.8.1/
[4] 
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts;hb=HEAD
[5] http://wenq.org/enindex.cgi?MicroHei%28en%29



*From*: 	Michal Suchanek
*Subject*: 	Re: fonts for gfxmenu, help needed
*Date*: 	Wed, 25 Nov 2009 17:04:59 +0100

------------------------------------------------------------------------

2009/11/25 feng shu <address@hidden>:
>/ 2009/11/25 Vladimir 'Ï-coder/phcoder' Serbinenko <address@hidden>:/
>/> Michal Suchanek wrote:/

>/>>/
>/>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly/
>/>> written in Latin, Chinese cannot./
>/>>/
>/> pinyin. I know it's disagreable to read for native speakers, but it's/
>/> similar for Arabic./
>
>/ show grub menu with pinyin? Âit is very very stupid./
>

I guess most people in Europe simply don't understand that pinyin is
unreadable.

Fortunately, displaying Chinese characters should be well within the
capabilities of current gfxterm although the font is likely poor
quality.

Any testers who can tell the difference between commonly used Chinese
fonts and GNU Unifont are welcome.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Felix Zielcke]

Am Mittwoch, den 25.11.2009, 23:38 -0500 schrieb Qianqian Fang:
> hi list
> 
> My friend brought me attention to this thread, and
> I am very glad to see a better CJK support is now
> on the agenda of grub. As a Chinese font developer,
> I am willing to help, share information or build
> fonts for this specific need.
> 
> I wasn't really following how fonts were used in grub,
> and still had the (wrong) impression that only 256
> glyphs are allowed for each file. After opening the
> overlay_2009-07-19 tarball, I saw large files such as
> unifont are included, so, I guess now grub is able
> to handle the full unicode (or BMP) fonts including
> CJK ones, is this correct? do they have to be bitmaps?

Even with the old .pff font format the whole unicode was possible but it
was just slow IIRC.
At least it was slow with first version of .pf2 or grub-mkfont.
The .pf2 format itself is bitmap but see below. As input for grub-mkfont
they can be TTF.

> If the answers to my above questions are "yes", then
> I think you may consider a customized version
> of "WenQuanYi Bitmap Song" [1], which is a multi-strike
> bitmap font containing >27000 Chinese Han glyphs
> at 9pt,10pt,10.5pt,11pt and 12pt sizes. The Latin
> part of this font are not "monospaced", but we
> can either merge it with other mono Latin fonts
> (GPL compatible), or use fallback to get around it.
> 
> I saw you already have the later version of
> GNU Unifont installed, if that's the case, then
> you can skip the 12pt of WenQuanYi Bitmap Song,
> because most of the CJK glyphs in Unifont 5.1
> were ported from WQY's bitmap font last year by
> Paul Hardy [2].

Yes in the Debian/Ubuntu packages we use Paul Hardy's version.

> About format, I don't know if you can use ttf
> file, or SFNT ttf file (with only embedded bitmaps).
> WQY Bitmap Song has an SFNT TTF version [3]. It appears
> that freetype2 works fine with it, but fontconfig
> has difficulties. Using SFNT TTF, the uncompressed
> font size is about 3M (with 9,10,11,12pt),which
> is fairly lightweight.
> 
> If grub happens to be able to process vector
> ttf fonts, I would recommend DroidSansFallback [4]
> or the derived WenQuanYi Micro Hei [5]. They both
> covers a huge span of languages, and the second one
> have a lot more CJK glyphs and both proportional
> and monospaced species.

As input format for grub-mkconf we support everything libfreetype
supports, so TTF too.

> Please let me know if you have any further comments,
> 
> Qianqian


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Felix Zielcke wrote:
> Even with the old .pff font format the whole unicode was possible but it
> was just slow IIRC.
> At least it was slow with first version of .pf2 or grub-mkfont.
> The .pf2 format itself is bitmap but see below. As input for grub-mkfont
> they can be TTF.
>   

that's great, does the font have to be monospaced (or
dual-width for CJK)? what code point range you want
this CJK font file to provide? CJK glyphs only?

> As input format for grub-mkconf we support everything libfreetype
> supports, so TTF too.
>   

I guess you meant grub-mkfont. If that's the case, i.e. grub can
handle gray-scale bitmaps, then, use grub-mkconf to convert
WenQuanYi Micro Hei (Mono) will be my second recommendation
next to the wqy bitmap song solution.

If grub happens to use fontconfig to handle fallback relationship,
you do need to be aware about this bug, as fontconfig does not
have everything to handle sfnt ttf format:
https://bugs.freedesktop.org/show_bug.cgi?id=23336

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/26 Qianqian Fang <fangqq@gmail.com>:
> Felix Zielcke wrote:
>>
>> Even with the old .pff font format the whole unicode was possible but it
>> was just slow IIRC.
>> At least it was slow with first version of .pf2 or grub-mkfont.
>> The .pf2 format itself is bitmap but see below. As input for grub-mkfont
>> they can be TTF.
>>
>
> that's great, does the font have to be monospaced (or

Grub is capable of displaying variable width fonts but monospace fonts
may be preferred for some uses.

> dual-width for CJK)? what code point range you want
> this CJK font file to provide? CJK glyphs only?

Ideally grub should use as few fonts as possible so a font with both
CJK glyphs and Latin glyphs is preferable.

As you pointed out the glyphs in Unifont are mostly ported from wqy
fonts so unifont would be one such font.

We may need a special font for Japanese and a method to load different
primary font when displaying the grub menu in Japanese is desired or
extend grub to support combining variant marks.

Unfortunately, unifont is only provided in single variant and size
which is most troublesome in my view.

I expect that theme authors would want at least two font variants
(Song, Hei) and some larger font sizes for captions or displaying
simple few line menu on high resolution screens.

>
>> As input format for grub-mkconf we support everything libfreetype
>> supports, so TTF too.
>>
>
> I guess you meant grub-mkfont. If that's the case, i.e. grub can
> handle gray-scale bitmaps, then, use grub-mkconf to convert

Grub does not support grayscale in its font format. The pf2 files are
a collection of 1bit deep transparency masks.

> WenQuanYi Micro Hei (Mono) will be my second recommendation
> next to the wqy bitmap song solution.
>
> If grub happens to use fontconfig to handle fallback relationship,
> you do need to be aware about this bug, as fontconfig does not
> have everything to handle sfnt ttf format:
> https://bugs.freedesktop.org/show_bug.cgi?id=23336

Grub does not use fontconfig.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Michal Suchanek wrote:
> Grub is capable of displaying variable width fonts but monospace fonts
> may be preferred for some uses.
> Ideally grub should use as few fonts as possible so a font with both
> CJK glyphs and Latin glyphs is preferable.
> As you pointed out the glyphs in Unifont are mostly ported from wqy
> fonts so unifont would be one such font.
> We may need a special font for Japanese and a method to load different
> primary font when displaying the grub menu in Japanese is desired or
> extend grub to support combining variant marks.
>
> Unfortunately, unifont is only provided in single variant and size
> which is most troublesome in my view.
> I expect that theme authors would want at least two font variants
> (Song, Hei) and some larger font sizes for captions or displaying
> simple few line menu on high resolution screens.
>   

ok, I think I am getting clear now. Grub can load pan-unicode
(1-bit) bitmap fonts of various sizes. Grub needs 1) good bitmap
fonts with CJK coverage (and possibility Latin) at multiple
point sizes, 2) preferably with Song and Hei styles as well as
3) Han glyph CJK variant support.

Personally, I would rank the likelihood of the above
goals in 1>3>2. Basically, for #1, WQY Bitmap Song (xfonts-wqy
in Debian/Ubuntu) is what you are looking for (together
with GNU unifont).

For #2, it depends on how grub handles language and fallback
and does need a lot of cautions, otherwise, it can be a pain.
AFAIK, there are not many good free Japanese bitmap fonts
covers the 9~12pt ranges. Mplus [1] bitmaps have OK quality,
but only have 8pt and 9pt (8pt is not a readable size); then
efonts [2], xfonts-intl-japanese, GNU intlfonts [3] and
HabianCJK [4] contain pretty much the same set of low-quality
Kanji bitmaps at 9pt, 10.5pt, 18pt and 24px, where IMHO,
the 9pt and 10.5pt are rather not readable; 18pt is sort of
ok, but wider than GNU unifont by 1px.

If you really want to include Japanese bitmaps, you may
also try to convert DroidSansJapanese [5]. But I think it
needs a lot of fine tuning in order to get the rasterized
glyphs readable.

For #3, it is difficult, and probably not necessary. The
differences between Song/Mincho and Hei/Gothic is rather
not distinguishable in screen sizes. You have to get above
20pt to see differences (which is largely weight different).
We call WQY bitmap song, but truly, it is not really the Song
style, because we eliminated all the serif due to small space.

If what you meant is to have "another style" in addition to
what we have in GNU unifont, then, you may rasterize WQY Micro Hei [6]
or WQY Zen Hei [7] to bitmaps, but again, I don't have faith on
the readability of the outcome unless someone spend years
to manually fine tune.


In summary, I think goal #1 is ready to go, #2 needs more
input from Japanese users, and some additional work; #3
needs a lot of work, and perhaps not really that important.

Also, I want to add that Japanese people CAN read
simplified-Chinese styled Kanji. It's not pleasant, but
not unrecognizable (it's like simplified Chinese users
can understand traditional Chinese, but they don't use it).


Qianqian


[1] http://mplus-fonts.sourceforge.jp/mplus-bitmap-fonts/index.html
[2] http://openlab.ring.gr.jp/efont/unicode/
[3] http://ftp.gnu.org/gnu/intlfonts/
[4] http://wakaba-web.hp.infoseek.co.jp/hcjk/
[5] 
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts;hb=HEAD 

[6] http://packages.debian.org/search?keywords=ttf-wqy-microhei
[7] http://packages.debian.org/search?keywords=ttf-wqy-zenhei

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Qianqian Fang wrote:
> ok, I think I am getting clear now. Grub can load pan-unicode
> (1-bit) bitmap fonts of various sizes. Grub needs 1) good bitmap
> fonts with CJK coverage (and possibility Latin) at multiple
> point sizes, 2) preferably with Song and Hei styles as well as
> 3) Han glyph CJK variant support.
>
> Personally, I would rank the likelihood of the above
> goals in 1>3>2. Basically, for #1, WQY Bitmap Song (xfonts-wqy
> in Debian/Ubuntu) is what you are looking for (together
> with GNU unifont).
>
> For #2,...
>
> For #3,...

sorry for the confusion on the numbering, when I say #2 or #3,
it refers to the likelihood sequence, i.e. #2 means
goal 3). and #3 means goal 2).

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/27 Qianqian Fang <fangqq@gmail.com>:
> Michal Suchanek wrote:
>>
>> Grub is capable of displaying variable width fonts but monospace fonts
>> may be preferred for some uses.
>> Ideally grub should use as few fonts as possible so a font with both
>> CJK glyphs and Latin glyphs is preferable.
>> As you pointed out the glyphs in Unifont are mostly ported from wqy
>> fonts so unifont would be one such font.
>> We may need a special font for Japanese and a method to load different
>> primary font when displaying the grub menu in Japanese is desired or
>> extend grub to support combining variant marks.
>>
>> Unfortunately, unifont is only provided in single variant and size
>> which is most troublesome in my view.
>> I expect that theme authors would want at least two font variants
>> (Song, Hei) and some larger font sizes for captions or displaying
>> simple few line menu on high resolution screens.
>>
>
> ok, I think I am getting clear now. Grub can load pan-unicode
> (1-bit) bitmap fonts of various sizes. Grub needs 1) good bitmap
> fonts with CJK coverage (and possibility Latin) at multiple
> point sizes, 2) preferably with Song and Hei styles as well as
> 3) Han glyph CJK variant support.

Grub currently does not support glyph variants. The best we can do to
render Japanese properly without much additional works is to load a
different font when the menu is supposed to be in Japanese.

>
> Personally, I would rank the likelihood of the above
> goals in 1>3>2. Basically, for #1, WQY Bitmap Song (xfonts-wqy
> in Debian/Ubuntu) is what you are looking for (together
> with GNU unifont).
>
> For #2, it depends on how grub handles language and fallback
> and does need a lot of cautions, otherwise, it can be a pain.
> AFAIK, there are not many good free Japanese bitmap fonts
> covers the 9~12pt ranges. Mplus [1] bitmaps have OK quality,
> but only have 8pt and 9pt (8pt is not a readable size); then
> efonts [2], xfonts-intl-japanese, GNU intlfonts [3] and
> HabianCJK [4] contain pretty much the same set of low-quality
> Kanji bitmaps at 9pt, 10.5pt, 18pt and 24px, where IMHO,
> the 9pt and 10.5pt are rather not readable; 18pt is sort of
> ok, but wider than GNU unifont by 1px.

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.

>
> If you really want to include Japanese bitmaps, you may
> also try to convert DroidSansJapanese [5]. But I think it
> needs a lot of fine tuning in order to get the rasterized
> glyphs readable.
>
> For #3, it is difficult, and probably not necessary. The
> differences between Song/Mincho and Hei/Gothic is rather
> not distinguishable in screen sizes. You have to get above
> 20pt to see differences (which is largely weight different).
> We call WQY bitmap song, but truly, it is not really the Song
> style, because we eliminated all the serif due to small space.

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.

>
> If what you meant is to have "another style" in addition to
> what we have in GNU unifont, then, you may rasterize WQY Micro Hei [6]
> or WQY Zen Hei [7] to bitmaps, but again, I don't have faith on
> the readability of the outcome unless someone spend years
> to manually fine tune.

I guess it's OK to have only one font face in small size if there
aren't any good alternatives.
I would prefer readability over customization in this case.
For Latin multiple usable font styles exist at this size but that's
because the glyphs are much simpler and fewer so it's easier to draw
them in such constrained space.

>
>
> In summary, I think goal #1 is ready to go, #2 needs more
> input from Japanese users, and some additional work; #3
> needs a lot of work, and perhaps not really that important.
>
> Also, I want to add that Japanese people CAN read
> simplified-Chinese styled Kanji. It's not pleasant, but
> not unrecognizable (it's like simplified Chinese users
> can understand traditional Chinese, but they don't use it).

I would prefer for grub to offer the option to render each language
correctly as long as it is reasonably possible with current grub
features and available fonts.

All the additional fonts need not ship with grub. It may suffice to
document which fonts look good in grub so that distribution packagers
can use grub-mkfont to convert them on the user's machine if the fonts
are installed.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

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.

> 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 Hei@24px: http://wenq.org/upload/microhei_24px.png
  WQY Micro Hei@32px: http://wenq.org/upload/microhei_32px.png

Song-style:
  Japanese Mincho@24px (efont f24): 
http://wenq.org/upload/efont_micho_24px.png
  Chinese Song@32px (uming): http://wenq.org/upload/uming_32px.png

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

Let me know if you need any additional information.

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/28 Qianqian Fang <fangqq@gmail.com>:
> 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
feature.


>
>> 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 Hei@24px: http://wenq.org/upload/microhei_24px.png
>  WQY Micro Hei@32px: http://wenq.org/upload/microhei_32px.png
>
> Song-style:
>  Japanese Mincho@24px (efont f24):
> http://wenq.org/upload/efont_micho_24px.png
>  Chinese Song@32px (uming): http://wenq.org/upload/uming_32px.png
>
> 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
fontconfig.

> 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?

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

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

I am sorry, I meant "fontforge", not fontconfig. Those are
the steps to prepare a bitmap font (in bdf format, then
you can convert it to pf2)

> 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.
>   

I don't think so, but you can try. A good resterization requires
the font itself to contain the so called "hints", either PS hints
or TTF hints. But most free CJK vector fonts don't have it
build-in. That's why I have the steps to produce those in
fontforge.

Autohint is fine, the same for PS hints. It is the truetype hint
that has a patent, but I heard it got expired this Oct. I don't know
if it has been renewed or not. Ubuntu ships byte-code-enabled
freetype. Debian doesn't (at least a few years ago).

> 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.
>   

As I said, to produce a good resterization, the font file need to
contain hints, but almost all free CJK fonts don't have. I don't
think grub can help in this aspect, unless you port the
"stem-extraction" code from fontforge, that's a lot of work.

> 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?
>   

I am not sure which glyph you are referring to, but if you
are talking about the AA-ed small-sized Han glyphs above each
bitmap, it is the direct rendering results from ZenHei by
freetype2, without embedded bitmaps and autohint, and
yes, they look blurry. In fact, all of the CJK fonts will look
blurry at that size. Fortunately, ZenHei has embedded bitmaps.

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

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Michal Suchanek wrote:
> 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?
>   
ok, now I see which glyph you were talking about. No, to me,
"灱" is not particularly ugly. It has comparable quality
to others. They are definitely sub-optimal compared with
the manually hinted bitmaps, but they are usable for this size.

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/28 Qianqian Fang <fangqq@gmail.com>:
> Michal Suchanek wrote:
>>
>> 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?
>>
>
> ok, now I see which glyph you were talking about. No, to me,
> "灱" is not particularly ugly. It has comparable quality
> to others. They are definitely sub-optimal compared with
> the manually hinted bitmaps, but they are usable for this size.

It's good enough to read the character but if I designed a theme with
this character in some large caption I would immediately start looking
for a font that has a decent glyph for this character. It's far from
nice to look at.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Michal Suchanek wrote:
> It's good enough to read the character but if I designed a theme with
> this character in some large caption I would immediately start looking
> for a font that has a decent glyph for this character. It's far from
> nice to look at.
>   

I was talking about "rasterization quality", do you mean
the aesthetics of the glyph topology/structure?

However, I am pretty sure you don't need to worry about
"灱" because it is an extremely rarely used character and
was only used in ancient literatures. As a matter of fact,
in the over 20,000 Han char. included in the fonts I mentioned,
the top 3,000~4,000 covers 99.6% of the use in modern Chinese [1].

[1] http://www.jiyili.net/thread-27521-1-1.html 
   (based on a national survey in 1980s)

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

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

Qianqian Fang wrote:
> Michal Suchanek wrote:
>> It's good enough to read the character but if I designed a theme with
>> this character in some large caption I would immediately start looking
>> for a font that has a decent glyph for this character. It's far from
>> nice to look at.
>>   
>
> I was talking about "rasterization quality", do you mean
> the aesthetics of the glyph topology/structure?
>
> However, I am pretty sure you don't need to worry about
> "灱" because it is an extremely rarely used character and
> was only used in ancient literatures. As a matter of fact,
> in the over 20,000 Han char. included in the fonts I mentioned,
> the top 3,000~4,000 covers 99.6% of the use in modern Chinese [1].
>
Is it possible to have a font with only these characters plus if
necessary some computer-specific characters? I don't expect users to
write poems in grub and so such reduced font would be well-suited for
applications when size matters (e.g. embedding grub2 into flash rom)
Another question: are glyphs imported into unifont from ttf fonts are
vector-based?
And also I would like to thank you and Michal that you answered most of
the questions I had about Chinese support even without me asking them :)
> [1] http://www.jiyili.net/thread-27521-1-1.html   (based on a national
> survey in 1980s)
>
>> Thanks
>>
>> Michal
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>   
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Is it possible to have a font with only these characters plus if
> necessary some computer-specific characters? I don't expect users to
> write poems in grub and so such reduced font would be well-suited for
> applications when size matters (e.g. embedding grub2 into flash rom)
>   
certainly we can. However the problem is I don't have char-frequency
statistics for Japanese Kanji/Korean Hanja, also even for Chinese,
it's from 1980s.

We can try IICore [1], which has about 10,000 char.

[1] http://www.ogcio.gov.hk/ccli/eng/structure/iicorecompare.html

> Another question: are glyphs imported into unifont from ttf fonts are
> vector-based?
>   

no, they are manually drawn, similar for WenQuanYi's bitmaps. Only that
way, you can ensure the clearest look in small glyph sizes (and
it took years).

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]

Qianqian Fang wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Is it possible to have a font with only these characters plus if
>> necessary some computer-specific characters? I don't expect users to
>> write poems in grub and so such reduced font would be well-suited for
>> applications when size matters (e.g. embedding grub2 into flash rom)
>>   
> certainly we can. However the problem is I don't have char-frequency
> statistics for Japanese Kanji/Korean Hanja,
AFAIK Hanja isn't used a lot and in GRUB2 particularly I see only names
which could possibly use Hanja. Also quick look into ko.po of glibc
doesn't reveal any Hanja (even that I can't read either they have
different appearence). But due to nature of Hangul of being basically
arranged syllables out of Jamo we need to include whole 111712
precomposed Hangul. And since even important font rendering engines
prefered to stay away from Jamo composing except when with historical
Jamo I feel like it would be inappropriate to make it in GRUB.
As for Kanji we could stick to Jōyō kanji
[http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji] (I think we can
reasonably suppose that all kanji needed for grub2 are within the school
scope)
However I don't pretend to be expert in either Kanji, Hanja, Hangul or
Hanzi, so feel free to correct me.
> also even for Chinese,
> it's from 1980s.
Are there any reasons to believe more sinograms came into general usage
and may be used by grub since then? Will have anyway to have
computer-specific glyphs too.
Is the list you provided about Traditional or Simplified Chinese? What
about the other variant?
>
> We can try IICore [1], which has about 10,000 char.
General-usage fonts are good since they are likely to contain all useful
(for GRUB) glyphs. It just starts to look that we can't significantly
reduce the size of unifont by removing not-so-useful glyphs. 10000 for
Simplified Chinese, 10000 for Traditional Chinese and 10000 for Hangul
and we already have half of BMP/unifont
>
> [1] http://www.ogcio.gov.hk/ccli/eng/structure/iicorecompare.html
>
>> Another question: are glyphs imported into unifont from ttf fonts are
>> vector-based?
>>   
>
> no, they are manually drawn, similar for WenQuanYi's bitmaps. Only that
> way, you can ensure the clearest look in small glyph sizes (and
> it took years).
>
Wow as a coder I would never have supposed that rasterisation would take
so much time and human intervention
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> AFAIK Hanja isn't used a lot and in GRUB2 particularly I see only names
> which could possibly use Hanja. Also quick look into ko.po of glibc
> doesn't reveal any Hanja (even that I can't read either they have
> different appearence). But due to nature of Hangul of being basically
> arranged syllables out of Jamo we need to include whole 111712
> precomposed Hangul. And since even important font rendering engines
> prefered to stay away from Jamo composing except when with historical
> Jamo I feel like it would be inappropriate to make it in GRUB.
> As for Kanji we could stick to Jōyō kanji
> [http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji] (I think we can
> reasonably suppose that all kanji needed for grub2 are within the school
> scope)
> However I don't pretend to be expert in either Kanji, Hanja, Hangul or
> Hanzi, so feel free to correct me.
>   

I am pretty sure there are a lot of options. But at this point,
I think I need a clear plan on 1) what pixel sizes, 2) what
the number of Hanzi characters and 3) what font styles (song/hei)
does grub project need.

In my previous emails, I summarized the resources that
I know of, including
1) free pan-unifont vector fonts that cover most CJK/nonCJK scripts
2) bitmap fonts that have CJK coverage at smaller font sizes
3) a procedure to produce better quality rasterization from vector
   fonts using fontforge

With these, I think you can pretty much do any combination/slicing
you want. I would be glad help to make these bitmap fonts once
you decide the specs on the fonts (listed above)

> Are there any reasons to believe more sinograms came into general usage
> and may be used by grub since then? Will have anyway to have
> computer-specific glyphs too.
>   
no, I don't think so. Ideographic characters are
quite stable now. For general usage, the charset is
fixed. What get evolved are their combinations,
which we called "words", for example, "电脑"，"手机".
All these characters are ancient, but the combinations
represent something new.

> Is the list you provided about Traditional or Simplified Chinese? What
> about the other variant?
>   

IICore is a combination of simplified/traditional/japanese/korean.

http://translate.googleusercontent.com/translate_c?hl=en&ie=UTF-8&sl=zh-CN&tl=en&u=http://zh.wikipedia.org/wiki/%25E5%259C%258B%25E9%259A%259B%25E8%25A1%25A8%25E6%2584%258F%25E6%2596%2587%25E5%25AD%2597%25E6%25A0%25B8%25E5%25BF%2583&prev=_t&rurl=translate.google.com&twu=1&usg=ALkJrhiQIu8BQBujT7zze99y_BlwfOCxZQ

> General-usage fonts are good since they are likely to contain all useful
> (for GRUB) glyphs. It just starts to look that we can't significantly
> reduce the size of unifont by removing not-so-useful glyphs. 10000 for
> Simplified Chinese, 10000 for Traditional Chinese and 10000 for Hangul
> and we already have half of BMP/unifont
>   

Maybe start with full BMP and see if you have any particular
difficulties coming up. Re-slice a BDF file is quite eazy.

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/29 Qianqian Fang <fangqq@gmail.com>:
> Michal Suchanek wrote:
>>
>> It's good enough to read the character but if I designed a theme with
>> this character in some large caption I would immediately start looking
>> for a font that has a decent glyph for this character. It's far from
>> nice to look at.
>>
>
> I was talking about "rasterization quality", do you mean
> the aesthetics of the glyph topology/structure?

Aestetics is relative but uniform stroke width is not.

>
> However, I am pretty sure you don't need to worry about
> "灱" because it is an extremely rarely used character and
> was only used in ancient literatures. As a matter of fact,
> in the over 20,000 Han char. included in the fonts I mentioned,
> the top 3,000~4,000 covers 99.6% of the use in modern Chinese [1].
>

Yes, I suspected it would not be a common character, my character
table does not list a meaning for it.

However, similar issue can be seen with the 刀 character in the
microhei_24px and microhei_32px rasterization. In fact, the stroke
width is almost inverted in these two rasterizations although they are
supposedly the same font.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Qianqian Fang]

Michal Suchanek wrote:
> Aestetics is relative but uniform stroke width is not.
>
> Yes, I suspected it would not be a common character, my character
> table does not list a meaning for it.
>
> However, similar issue can be seen with the 刀 character in the
> microhei_24px and microhei_32px rasterization. In fact, the stroke
> width is almost inverted in these two rasterizations although they are
> supposedly the same font.
>   

I agree with you that the CJK autohinter is far from perfect.
It does a much worse job in smaller sizes.

Actually, you can find the unit that does the cjk autohinting, see

http://opensource.apple.com/source/X11proto/X11proto-15.5/freetype/freetype-2.3.9/src/autofit/afcjk.c
(this is a older version though, but just give you an idea)

if anyone want to improve the algorithm in this unit, that
will be really useful.

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

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/30 Qianqian Fang <fangqq@gmail.com>:
> Michal Suchanek wrote:
>>
>> Aestetics is relative but uniform stroke width is not.
>>
>> Yes, I suspected it would not be a common character, my character
>> table does not list a meaning for it.
>>
>> However, similar issue can be seen with the 刀 character in the
>> microhei_24px and microhei_32px rasterization. In fact, the stroke
>> width is almost inverted in these two rasterizations although they are
>> supposedly the same font.
>>
>
> I agree with you that the CJK autohinter is far from perfect.
> It does a much worse job in smaller sizes.

If it does decent job on larger font sizes then perhaps we could
render a large enough font and rely on bitmap fonts for smaller sizes.

I guess I should also install some more fonts and try to convert them
to bitmap in Fontforge.

>
> Actually, you can find the unit that does the cjk autohinting, see
>
> http://opensource.apple.com/source/X11proto/X11proto-15.5/freetype/freetype-2.3.9/src/autofit/afcjk.c
> (this is a older version though, but just give you an idea)
>
> if anyone want to improve the algorithm in this unit, that
> will be really useful.
>

I can tell a uniform line thickness when I see it but if it was easy
to get with the autohinter surely somebody would fix it up.


Thanks

Michal

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/30 Michal Suchanek <hramrach@centrum.cz>:
> 2009/11/30 Qianqian Fang <fangqq@gmail.com>:
>> Michal Suchanek wrote:
>>>
>>> Aestetics is relative but uniform stroke width is not.
>>>
>>> Yes, I suspected it would not be a common character, my character
>>> table does not list a meaning for it.
>>>
>>> However, similar issue can be seen with the 刀 character in the
>>> microhei_24px and microhei_32px rasterization. In fact, the stroke
>>> width is almost inverted in these two rasterizations although they are
>>> supposedly the same font.
>>>
>>
>> I agree with you that the CJK autohinter is far from perfect.
>> It does a much worse job in smaller sizes.
>
> If it does decent job on larger font sizes then perhaps we could
> render a large enough font and rely on bitmap fonts for smaller sizes.
>
> I guess I should also install some more fonts and try to convert them
> to bitmap in Fontforge.
>

I tried rasterizing Arphic fonts in Fontforge and I am disappointed.

First, fontforge sucks at this kind of task. There is no reasonable
way to select multiple glyphs, save a Unicode range. You can choose
them one by one or drag by mouse. The semantic of drag operation is
different on selected and non-selected glyphs. Pressing Esc to get out
of menu or clicking somewhere deselects the glyphs again with no way
of re-selecting the glyphs I was working with. Terrible user
interface.

The results of rasterization are also disappointing. The UMingTW font
seems somewhat reasonable at 48 and 64 px (but not 52 px so it's
probably just a matter of skimming through more glyphs to find some
examples of terrible rasterization).

In UKaiTW there is no problem with the 刀 character because its strokes
are slanted enough to not get turned into a line with width-stepping
but there is a problem with 口 and similar glyphs. The problem are
near-vertical or near-horizontal lines that get rasterized quite
poorly. Glyphs with multiple vertical or horizontal strokes often get
strokes of different widths because some of the strokes get rasterized
on the pixel boundary while others do not.

The same issues can be seen in the outline view without antialiasing,
and antialiasing greatly improves the glyph shapes, and at least for
me it improves readability as well.

So to me rasterizing to bitmaps looks like a dead end. We either need
grayscale support or vector support or take only the limited set of
fonts which are manually drawn as bitmaps.

Thanks

Michal

fonts for gfxmenu, help needed

[Robert Millan]

Hi,

Help is needed in order to provide the last bit that will make gfxmenu
functional: fonts of multiple sizes.

The sample tarball at http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz
includes a set of prebuilt fonts.  They were built using a Java utility
which ended up being replaced with grub-mkfont in our repository.

In order to provide the basic infrastructure so that theme authors can
begin developing their artwork, we need GRUB to build fonts from the original
unifont files (unifont.bdf or unifont.pcf.gz).

Can someone figure out appropiate parameters for grub-mkfont, such that
when applied on unifont.bdf or unifont.pcf.gz they will output suitable
PF2 font files?  A font file is suitable if it can be used to replace the
prebuilt ones in overlay_2009-07-19.tar.gz and its themes can still use
them.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/24 Robert Millan <rmh@aybabtu.com>:
>
> Hi,
>
> Help is needed in order to provide the last bit that will make gfxmenu
> functional: fonts of multiple sizes.
>
> The sample tarball at http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz
> includes a set of prebuilt fonts.  They were built using a Java utility
> which ended up being replaced with grub-mkfont in our repository.
>
> In order to provide the basic infrastructure so that theme authors can
> begin developing their artwork, we need GRUB to build fonts from the original
> unifont files (unifont.bdf or unifont.pcf.gz).
>
> Can someone figure out appropiate parameters for grub-mkfont, such that
> when applied on unifont.bdf or unifont.pcf.gz they will output suitable
> PF2 font files?  A font file is suitable if it can be used to replace the
> prebuilt ones in overlay_2009-07-19.tar.gz and its themes can still use
> them.

I suspect what you are asking is impossible.

As far as I understand unifont is a single bitmap font in a single
pixel size and the tarball you sent contains multiple font faces in
multiple sizes.

It could be achieved by converting the said fonts rather than unifont
but it seems you want to avoid that for some reason.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Robert Millan]

On Tue, Nov 24, 2009 at 04:27:13PM +0100, Michal Suchanek wrote:
> 
> I suspect what you are asking is impossible.
> 
> As far as I understand unifont is a single bitmap font in a single
> pixel size and the tarball you sent contains multiple font faces in
> multiple sizes.

Any idea how were those fonts built, then?

> It could be achieved by converting the said fonts rather than unifont
> but it seems you want to avoid that for some reason.

Why would I want to convert those fonts?  My goal is figuring out how to
provide suitable font files out of the usual selection of free fonts that
is provided by distributors.  So far I only know of unifont in this
selection, but there's certainly more.  Can you help?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: fonts for gfxmenu, help needed

[Colin D Bennett]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On Tue, 24 Nov 2009 18:35:55 +0100
Robert Millan <rmh@aybabtu.com> wrote:

> On Tue, Nov 24, 2009 at 04:27:13PM +0100, Michal Suchanek wrote:
> > 
> > I suspect what you are asking is impossible.
> > 
> > As far as I understand unifont is a single bitmap font in a single
> > pixel size and the tarball you sent contains multiple font faces in
> > multiple sizes.
> 
> Any idea how were those fonts built, then?

I just took a bunch of fonts from my Gentoo Linux system and converted
them.  It is just a quick demonstration of how many types, sizes, and
styles of fonts can be used (e.g., small to huge; sans-serif,
monospaced, and serif; italic and normal; etc.).

> Why would I want to convert those fonts?  My goal is figuring out how
> to provide suitable font files out of the usual selection of free
> fonts that is provided by distributors.  So far I only know of
> unifont in this selection, but there's certainly more.  Can you help?

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 (the Liberation font series?  I know there must be a
number of free fonts we can use.  Most won't support full Unicode
though, but by using font fallback we can search for glyphs missing
from the primary font in some language-specific fallback fonts).

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

Colin D Bennett wrote:
> On Tue, 24 Nov 2009 18:35:55 +0100
> Robert Millan <rmh@aybabtu.com> wrote:
>
>   
>> On Tue, Nov 24, 2009 at 04:27:13PM +0100, Michal Suchanek wrote:
>>     
>>> I suspect what you are asking is impossible.
>>>
>>> As far as I understand unifont is a single bitmap font in a single
>>> pixel size and the tarball you sent contains multiple font faces in
>>> multiple sizes.
>>>       
>> Any idea how were those fonts built, then?
>>     
>
> I just took a bunch of fonts from my Gentoo Linux system and converted
> them.  It is just a quick demonstration of how many types, sizes, and
> styles of fonts can be used (e.g., small to huge; sans-serif,
> monospaced, and serif; italic and normal; etc.).
>   
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
>   
>> Why would I want to convert those fonts?  My goal is figuring out how
>> to provide suitable font files out of the usual selection of free
>> fonts that is provided by distributors.  So far I only know of
>> unifont in this selection, but there's certainly more.  Can you help?
>>     
>
> 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)
>
> Regards,
> Colin
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Robert Millan]

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

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 Robert Millan <rmh@aybabtu.com>:
> 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.

However, grub has decent scaling that can be applied to images so it
can be applied to fonts to get things started. Then we need 2-3 type
faces in a single size which is probably much easier to get.

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

 - 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.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 5010 bytes --]

Michal Suchanek wrote:
> 2009/11/25 Robert Millan <rmh@aybabtu.com>:
>   
>> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Michal Suchanek wrote:

>>
>> 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 difference is that the font is only a bitmap whereas scaling
inside grub can do blending which should give much better results than
scaling bitmap into another bitmap.

> 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

Typically people want at the very least

 - serif font
 - sans-serif font
 - multiple sizes of the above so that the menu can have a larger
title / be scaled to different screen sizes

Sure, some would want their exact font in which the logo of their
distribution is writen but this is outside of scope of Grub.

>>  - 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
>

Not being able to use combining diacritics sucks. Does that mean that
grub won't be able to draw decomposed Unicode strings?

Either way the four points above are things that gfxterm simply does
not support whereas Unihan flamewars are inherent feature of Unicode
and the gfxterm technically should be able to display CJK languages
given a good enough font.

Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
written in Latin, Chinese cannot.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

Michal Suchanek wrote:
>
> The difference is that the font is only a bitmap whereas scaling
> inside grub can do blending which should give much better results than
> scaling bitmap into another bitmap.
>
>   
What do you mean by blending? Do you mean pixels with alpha channels?
>> 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
>>     
>
> Typically people want at the very least
>
>  - serif font
>  - sans-serif font
>  - multiple sizes of the above so that the menu can have a larger
> title / be scaled to different screen sizes
>
> Sure, some would want their exact font in which the logo of their
> distribution is writen but this is outside of scope of Grub.
>
>   
>>>  - 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
>>
>>     
>
> Not being able to use combining diacritics sucks. Does that mean that
> grub won't be able to draw decomposed Unicode strings?
>   
I haven't checked. But I suppose it doesn't since it stores one
codepoint per on-screen place
> Either way the four points above are things that gfxterm simply does
> not support 
It may need a major changes to support :( And these changes may
propagate through whole terminal system (gotoxy concept is flawed)
> whereas Unihan flamewars are inherent feature of Unicode
>   
You seem have missed variant selectors
(last paragraph of
http://en.wikipedia.org/wiki/Unihan#Graphemes_versus_glyphs)
And we're back to multichar per on-screen place problem
> and the gfxterm technically should be able to display CJK languages
> given a good enough font.
>
> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
> written in Latin, Chinese cannot.
>   
pinyin. I know it's disagreable to read for native speakers, but it's
similar for Arabic.
In worst case we can just say Japanese people to install Japanese fonts
only and bear with Chinese having a bit wrong rendering and vice-versa.
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Michal Suchanek wrote:
>>
>> The difference is that the font is only a bitmap whereas scaling
>> inside grub can do blending which should give much better results than
>> scaling bitmap into another bitmap.
>>
>>
> What do you mean by blending? Do you mean pixels with alpha channels?

I mean that you can render the font bitmap in its native size to a
32bit surface and use the bilinear scaling feature to resize that, for
example. The advantage of on-the-fly scaling is that you really need
only a single font, the differently sized glyphs are created as
needed. The disadvantage over native fonts of different sizes is, of
course, lower quality.

If you render the glyph to a differently sized bitmap with some
nearest-fit algorithm (because there isn't really any option here) the
result would be vastly inferior I would expect. As fonts are bitmaps
this is the only option for scaling in grub-mkfont.

> You seem have missed variant selectors
> (last paragraph of
> http://en.wikipedia.org/wiki/Unihan#Graphemes_versus_glyphs)
> And we're back to multichar per on-screen place problem
>> and the gfxterm technically should be able to display CJK languages
>> given a good enough font.
>>
>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>> written in Latin, Chinese cannot.
>>
> pinyin. I know it's disagreable to read for native speakers, but it's

That doesn't really help. There isn't really a canonical reading every
Chinese speaking person is supposed to understand, and even if you
choose one as the standard it's not possible to derive the meaning of
a word from the reading but it is possible from the Chinese character.

Hebrew and Arabic use letters that correspond to consonants so anybody
who knows the language and Latin alphabet should be able to read a
Latin transcription, though possibly with gritting teeth.

> similar for Arabic.
> In worst case we can just say Japanese people to install Japanese fonts
> only and bear with Chinese having a bit wrong rendering and vice-versa.

Yes, that's certainly a possibility but one has to be aware of this
limitation and perhaps mention it somewhere.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

Michal Suchanek wrote:
> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> Michal Suchanek wrote:
>>     
>>> The difference is that the font is only a bitmap whereas scaling
>>> inside grub can do blending which should give much better results than
>>> scaling bitmap into another bitmap.
>>>
>>>
>>>       
>> What do you mean by blending? Do you mean pixels with alpha channels?
>>     
>
> I mean that you can render the font bitmap in its native size to a
> 32bit surface and use the bilinear scaling feature to resize that, for
> example. 
It's equivalent to have partially transparent pixels
> The advantage of on-the-fly scaling is that you really need
> only a single font, the differently sized glyphs are created as
> needed. The disadvantage over native fonts of different sizes is, of
> course, lower quality.
>   
I still don't think on-the-fly scaling, especially complicated one is a
good solution to a problem.
I think the est way is to find a set of TrueType fonts with adapted
typefaces, render them to different sizes and add unifont as fallback.
We could use on-the-fly cached scaling for unifont fallback and so its
slowness will be less of a problem and may be better alternative than
time required to load multiple versions of unifont. Also quality in this
case is less of an issue too.
> That doesn't really help. There isn't really a canonical reading every
> Chinese speaking person is supposed to understand, and even if you
> choose one as the standard it's not possible to derive the meaning of
> a word from the reading but it is possible from the Chinese character.
>   
Chinese people are usually familiar with either pinyin or
Cantonese-based transliteration since they are widely used in Input Methods
> Hebrew and Arabic use letters that correspond to consonants so anybody
> who knows the language and Latin alphabet should be able to read a
> Latin transcription, though possibly with gritting teeth.
>
>   
Transliterating Arabic isn't good idea. It will make GRUB look like a
big SMS
But we don't speak of same issues either. The only issues is that
Japanese or Chinese may see a similar symbol with similar rendering but
from other language. It may be unnice but is understandable. If we
really care about right symbol I suggest to use glyph variant codes.
>> similar for Arabic.
>> In worst case we can just say Japanese people to install Japanese fonts
>> only and bear with Chinese having a bit wrong rendering and vice-versa.
>>     
>
> Yes, that's certainly a possibility but one has to be aware of this
> limitation and perhaps mention it somewhere.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[feng shu]

2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Michal Suchanek wrote:
>>
>> The difference is that the font is only a bitmap whereas scaling
>> inside grub can do blending which should give much better results than
>> scaling bitmap into another bitmap.
>>
>>
> What do you mean by blending? Do you mean pixels with alpha channels?
>>> 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
>>>
>>
>> Typically people want at the very least
>>
>>  - serif font
>>  - sans-serif font
>>  - multiple sizes of the above so that the menu can have a larger
>> title / be scaled to different screen sizes
>>
>> Sure, some would want their exact font in which the logo of their
>> distribution is writen but this is outside of scope of Grub.
>>
>>
>>>>  - 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
>>>
>>>
>>
>> Not being able to use combining diacritics sucks. Does that mean that
>> grub won't be able to draw decomposed Unicode strings?
>>
> I haven't checked. But I suppose it doesn't since it stores one
> codepoint per on-screen place
>> Either way the four points above are things that gfxterm simply does
>> not support
> It may need a major changes to support :( And these changes may
> propagate through whole terminal system (gotoxy concept is flawed)
>> whereas Unihan flamewars are inherent feature of Unicode
>>
> You seem have missed variant selectors
> (last paragraph of
> http://en.wikipedia.org/wiki/Unihan#Graphemes_versus_glyphs)
> And we're back to multichar per on-screen place problem
>> and the gfxterm technically should be able to display CJK languages
>> given a good enough font.
>>
>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>> written in Latin, Chinese cannot.
>>
> pinyin. I know it's disagreable to read for native speakers, but it's
> similar for Arabic.

show grub menu with pinyin?  it is very very stupid.

> In worst case we can just say Japanese people to install Japanese fonts
> only and bear with Chinese having a bit wrong rendering and vice-versa.
>> Thanks
>>
>> Michal
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 feng shu <tumashu@gmail.com>:
> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> Michal Suchanek wrote:

>>>
>>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>>> written in Latin, Chinese cannot.
>>>
>> pinyin. I know it's disagreable to read for native speakers, but it's
>> similar for Arabic.
>
> show grub menu with pinyin?  it is very very stupid.
>

I guess most people in Europe simply don't understand that pinyin is
unreadable.

Fortunately, displaying Chinese characters should be well within the
capabilities of current gfxterm although the font is likely poor
quality.

Any testers who can tell the difference between commonly used Chinese
fonts and GNU Unifont are welcome.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

Michal Suchanek wrote:
> 2009/11/25 feng shu <tumashu@gmail.com>:
>   
>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>     
>>> Michal Suchanek wrote:
>>>       
>
>   
>>>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>>>> written in Latin, Chinese cannot.
>>>>
>>>>         
>>> pinyin. I know it's disagreable to read for native speakers, but it's
>>> similar for Arabic.
>>>       
>> show grub menu with pinyin?  it is very very stupid.
>>
>>     
I was mainly trying to say that menu with Russian or Arabic
transliteration wouldn't make much sense either.
>
> I guess most people in Europe simply don't understand that pinyin is
> unreadable.
>   
You're right I don't understand it. So please enlighten me. According to
wikipedia pinyin is used for teaching Chinese language in school, and
pinyin is a major input method used. Pinyin when used with all
diacritics represents the words as they would be spoken aloud and yet
you say that it's completely unreadable even by Mandarin speakers. I
understand that a speaker of Cantonese or wǔ wouldn't be able to
understand it because pronunciation is different but why is it the case
for Mandarin speaker too?
Another question: do you think vertical (top-to-bottom instead of
left-to-right) menu themes would be useful for Chinese and Japanese
computers?
> Fortunately, displaying Chinese characters should be well within the
> capabilities of current gfxterm although the font is likely poor
> quality.
>
>   
Better fonts can be included but I would prefer not loading them by
default instead if user needs it. Perhaps our grub.cfg generation system
could scan configfiles and add fonts appropriately?
> Any testers who can tell the difference between commonly used Chinese
> fonts and GNU Unifont are welcome.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Michal Suchanek wrote:
>> 2009/11/25 feng shu <tumashu@gmail.com>:
>>
>>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>> Michal Suchanek wrote:
>>>>
>>
>>
>>>>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>>>>> written in Latin, Chinese cannot.
>>>>>
>>>>>
>>>> pinyin. I know it's disagreable to read for native speakers, but it's
>>>> similar for Arabic.
>>>>
>>> show grub menu with pinyin?  it is very very stupid.
>>>
>>>
> I was mainly trying to say that menu with Russian or Arabic
> transliteration wouldn't make much sense either.
>>
>> I guess most people in Europe simply don't understand that pinyin is
>> unreadable.
>>
> You're right I don't understand it. So please enlighten me. According to
> wikipedia pinyin is used for teaching Chinese language in school, and
> pinyin is a major input method used. Pinyin when used with all
> diacritics represents the words as they would be spoken aloud and yet
> you say that it's completely unreadable even by Mandarin speakers. I
> understand that a speaker of Cantonese or wǔ wouldn't be able to
> understand it because pronunciation is different but why is it the case
> for Mandarin speaker too?

Yes, if you are non-Chinese you would probably learn pinyin and it
indeed records the pronunciation. However, it is not necessary to
learn pinyin to read Chinese so I suspect Chinese would not learn
Mandarin and pinyin just to learn how to write.

It is also feasible to use a PC without knowing pinyin. Writing may be
difficult then but not everybody needs to write and alternate input
methods exist.

Pinyin is not readable because it conveys less information than the
Chinese character would. Many words are pronounced the same and would
have the same pinyin representation but would be written with a
distinct Chinese character.

In spoken Chinese you have to ensure enough context for the word to be
understood (either use reasonably long non-ambiguous sentence or use
previous conversation as context). In writing one or few characters
are often enough to convey a distinct meaning regardless of context
(ie in a menu entry).

> Another question: do you think vertical (top-to-bottom instead of
> left-to-right) menu themes would be useful for Chinese and Japanese
> computers?

I think they would be nice to have but not terribly useful.

It is completely feasible to read and write CJK in LTR order, and most
computer software uses that order for simplicity.
Many magazines seem to be typeset that way as well so this is not
limited to computers.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[feng shu]

2009/11/26 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Michal Suchanek wrote:
>> 2009/11/25 feng shu <tumashu@gmail.com>:
>>
>>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>> Michal Suchanek wrote:
>>>>
>>
>>
>>>>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>>>>> written in Latin, Chinese cannot.
>>>>>
>>>>>
>>>> pinyin. I know it's disagreable to read for native speakers, but it's
>>>> similar for Arabic.
>>>>
>>> show grub menu with pinyin?  it is very very stupid.
>>>
>>>
> I was mainly trying to say that menu with Russian or Arabic
> transliteration wouldn't make much sense either.
>>
>> I guess most people in Europe simply don't understand that pinyin is
>> unreadable.
>>
> You're right I don't understand it. So please enlighten me. According to
> wikipedia pinyin is used for teaching Chinese language in school, and
> pinyin is a major input method used. Pinyin when used with all

pinyin is used to teach childern read Chinese,  but you would find that

1. may Chinese chars (maybe 10 ,maybe 100 maybe 500)  have a  pinyin
，for example ：

ai :

艾	ài,yì,	 	阨	ài,
伌	ài,		佁	ǎi,yǐ,
毐	ǎi,		哎	āi,
哀	āi,		诶	āi,
昹	ǎi,		爱	ài,
砹	ài,		唉	ài,āi,
娭	āi,xī,		挨	ái,āi,
埃	āi,		捱	ái,
娾	ǎi,		啀	ái,
硋	ài,		閊	cī kā ɑī lū,
皑	ái,		欸	ǎi,ēi,
隘	ài,		凒	ái,
溾	āi,		塧	ài,
溰	ái,		嫒	ài,
嗳	ài,ǎi,āi,	13	嗌	ài,yì,
愛	ài,		矮	ǎi,
碍	ài, 	        魞     ɑì lì,
锿	āi,		瑷	ài,
敳	ái,		暧	ài,
敱	ái,		嘊	ái,
叆	ài,		蔼	ǎi,
僾	ài,	        皚     ái,
躷	ǎi,		壒	ài,
懓	ài,		薆	ài,
噫	ài,yì,yī,	噯	ǎi,
濭	ǎi,		嬡	ài,
鴱	ài,		騃	ái,
懝	ài,		曖	ài,
璦	ài,		餲	ài,hé,
鎄	āi,		癌	ái,
瞹	ài,		皧	ài,
馤	ài,		霭	ǎi,
﨟	ai		礙	ài,
譪	ǎi,		藹	ǎi,
譺	ài,		鑀	ài,
鱛	ɑī suǒ,	靄	ǎi,
鱫	ɑi,		靉	ài,


2. a Chinese char may have many pinyin, see above



> diacritics represents the words as they would be spoken aloud and yet
> you say that it's completely unreadable even by Mandarin speakers. I
> understand that a speaker of Cantonese or wǔ wouldn't be able to
> understand it because pronunciation is different but why is it the case
> for Mandarin speaker too?
> Another question: do you think vertical (top-to-bottom instead of
> left-to-right) menu themes would be useful for Chinese and Japanese
> computers?
>> Fortunately, displaying Chinese characters should be well within the
>> capabilities of current gfxterm although the font is likely poor
>> quality.
>>
>>
> Better fonts can be included but I would prefer not loading them by
> default instead if user needs it. Perhaps our grub.cfg generation system
> could scan configfiles and add fonts appropriately?
>> Any testers who can tell the difference between commonly used Chinese
>> fonts and GNU Unifont are welcome.
>>
>> Thanks
>>
>> Michal
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

Re: fonts for gfxmenu, help needed

[feng shu]

2009/11/26 Michal Suchanek <hramrach@centrum.cz>:
> 2009/11/25 feng shu <tumashu@gmail.com>:
>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>> Michal Suchanek wrote:
>
>>>>
>>>> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly
>>>> written in Latin, Chinese cannot.
>>>>
>>> pinyin. I know it's disagreable to read for native speakers, but it's
>>> similar for Arabic.
>>
>> show grub menu with pinyin?  it is very very stupid.
>>
>
> I guess most people in Europe simply don't understand that pinyin is
> unreadable.
>
> Fortunately, displaying Chinese characters should be well within the
> capabilities of current gfxterm although the font is likely poor
> quality.

you can find ttf fonts : wqy-zenhei and wqy-microhei

http://sourceforge.net/projects/wqy/files/

>
> Any testers who can tell the difference between commonly used Chinese
> fonts and GNU Unifont are welcome.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: fonts for gfxmenu, help needed

[Michal Suchanek]

2009/11/25 Robert Millan <rmh@aybabtu.com>:
> 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).
>

Does grub-mkfont support writing .pf2 files from any font?

IIRC there was a glyph searching optimization committed into Grub
which uses binary search instead of linear search.
This requires either that font glyphs are sorted by Unicode codepoint
(which they supposedly are in unifont) or that grub-mkfont sorts them
while creating the .pf2 file.

Thanks

Michal

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

Michal Suchanek wrote:
> 2009/11/25 Robert Millan <rmh@aybabtu.com>:
>   
>> 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).
>>
>>     
>
> Does grub-mkfont support writing .pf2 files from any font?
>
> IIRC there was a glyph searching optimization committed into Grub
> which uses binary search instead of linear search.
> This requires either that font glyphs are sorted by Unicode codepoint
> (which they supposedly are in unifont) or that grub-mkfont sorts them
> while creating the .pf2 file.
>
>   
grub-mkfont should sort ranges, it's clearly a bug. Patch to fix
grub-mkfont is welcome (you can use qsort to sort them)
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

Michal Suchanek wrote:
> 2009/11/24 Robert Millan <rmh@aybabtu.com>:
>   
>> Hi,
>>
>> Help is needed in order to provide the last bit that will make gfxmenu
>> functional: fonts of multiple sizes.
>>
>> The sample tarball at http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz
>> includes a set of prebuilt fonts.  They were built using a Java utility
>> which ended up being replaced with grub-mkfont in our repository.
>>
>> In order to provide the basic infrastructure so that theme authors can
>> begin developing their artwork, we need GRUB to build fonts from the original
>> unifont files (unifont.bdf or unifont.pcf.gz).
>>
>> Can someone figure out appropiate parameters for grub-mkfont, such that
>> when applied on unifont.bdf or unifont.pcf.gz they will output suitable
>> PF2 font files?  A font file is suitable if it can be used to replace the
>> prebuilt ones in overlay_2009-07-19.tar.gz and its themes can still use
>> them.
>>     
>
> I suspect what you are asking is impossible.
>
> As far as I understand unifont is a single bitmap font in a single
> pixel size and the tarball you sent contains multiple font faces in
> multiple sizes.
>   
While usually it's a bad idea to scale bitmap font it can be done and
for our uses (mainly downscale and a bit of upscale) it may be
appropriate for our usage.
> It could be achieved by converting the said fonts rather than unifont
> but it seems you want to avoid that for some reason.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: fonts for gfxmenu, help needed

[Felix Zielcke]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

Am Dienstag, den 24.11.2009, 19:12 +0100 schrieb Vladimir
'φ-coder/phcoder' Serbinenko:
> Michal Suchanek wrote:
> > 2009/11/24 Robert Millan <rmh@aybabtu.com>:
> >   
> >> Hi,
> >>
> >> Help is needed in order to provide the last bit that will make
> gfxmenu
> >> functional: fonts of multiple sizes.
> >>
> >> The sample tarball at
> http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz
> >> includes a set of prebuilt fonts.  They were built using a Java
> utility
> >> which ended up being replaced with grub-mkfont in our repository.
> >>
> >> In order to provide the basic infrastructure so that theme authors
> can
> >> begin developing their artwork, we need GRUB to build fonts from
> the original
> >> unifont files (unifont.bdf or unifont.pcf.gz).
> >>
> >> Can someone figure out appropiate parameters for grub-mkfont, such
> that
> >> when applied on unifont.bdf or unifont.pcf.gz they will output
> suitable
> >> PF2 font files?  A font file is suitable if it can be used to
> replace the
> >> prebuilt ones in overlay_2009-07-19.tar.gz and its themes can still
> use
> >> them.
> >>     
> >
> > I suspect what you are asking is impossible.
> >
> > As far as I understand unifont is a single bitmap font in a single
> > pixel size and the tarball you sent contains multiple font faces in
> > multiple sizes.
> >   
> While usually it's a bad idea to scale bitmap font it can be done and
> for our uses (mainly downscale and a bit of upscale) it may be
> appropriate for our usage.

grub-mkfont supports as input files everything libfreetype supports.
TTF is supported and there's also a unifont.ttf.
But our own .pf2 format is bitmap not outline.
-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 490 bytes --]