Re: fonts for gfxmenu, help needed
2009/11/30 Michal Suchanek : > 2009/11/30 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. > > 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/30 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. 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/29 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? 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 ___ 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 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. 1 for Simplified Chinese, 1 for Traditional Chinese and 1 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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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. 1 for Simplified Chinese, 1 for Traditional Chinese and 1 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 signature.asc Description: OpenPGP digital signature ___ 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 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). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/28 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. 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/28 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. 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 h...@24px: http://wenq.org/upload/microhei_24px.png > WQY Micro h...@32px: http://wenq.org/upload/microhei_32px.png > > Song-style: > Japanese min...@24px (efont f24): > http://wenq.org/upload/efont_micho_24px.png > Chinese s...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 h...@24px: http://wenq.org/upload/microhei_24px.png WQY Micro h...@32px: http://wenq.org/upload/microhei_32px.png Song-style: Japanese min...@24px (efont f24): http://wenq.org/upload/efont_micho_24px.png Chinese s...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/27 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. 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 addit
Re: fonts for gfxmenu, help needed
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). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/26 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 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 : / 2009/11/25 Vladimir 'Ï-coder/phcoder' Serbinenko :/ /> 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/26 Michal Suchanek : > 2009/11/25 feng shu : >> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : >>> 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 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/26 Vladimir 'φ-coder/phcoder' Serbinenko : > Michal Suchanek wrote: >> 2009/11/25 feng shu : >> >>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : >>> 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 > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : > Michal Suchanek wrote: >> 2009/11/25 feng shu : >> >>> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : >>> 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: > 2009/11/25 feng shu : > >> 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : >> >>> 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 feng shu : > 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : >> 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : > 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 > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: > 2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : > >> 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : > 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: > 2009/11/25 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). >> >> > > 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 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). > 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko : > 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: > 2009/11/25 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). >> >> > > 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mai
Re: fonts for gfxmenu, help needed
2009/11/25 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). > 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Colin D Bennett wrote: > On Tue, 24 Nov 2009 18:35:55 +0100 > Robert Millan 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
On Tue, 24 Nov 2009 18:35:55 +0100 Robert Millan 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 signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Am Dienstag, den 24.11.2009, 19:12 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Michal Suchanek wrote: > > 2009/11/24 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. > >> > > > > 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: > 2009/11/24 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. >> > > 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 signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
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." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/24 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. 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
