2009/11/25 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>: > Michal Suchanek wrote: >> >> The difference is that the font is only a bitmap whereas scaling >> inside grub can do blending which should give much better results than >> scaling bitmap into another bitmap. >> >> > What do you mean by blending? Do you mean pixels with alpha channels? >>> The best way to choose between pre-scaling and scaling in grub is >>> benchmarking. Multiple fonts take longer to load but scaling even with >>> caching is likely to cause more performance hit. >>> How much fonts does an author need? We need either decrease number of >>> fonts simultaneously used or have faster font loader (both in preference). >>> As Robert said most important is to get things going and theme creators >>> can use other free fonts as well >>> >> >> Typically people want at the very least >> >> - serif font >> - sans-serif font >> - multiple sizes of the above so that the menu can have a larger >> title / be scaled to different screen sizes >> >> Sure, some would want their exact font in which the logo of their >> distribution is writen but this is outside of scope of Grub. >> >> >>>> - there is a problem with Simplified Chinese/Traditional >>>> Chinese/Japanese. Some of the glyphs used by these writing systems >>>> have the same unicode codepoint but are slightly different in each. To >>>> get these rendered correctly you need special font for each. Blame the >>>> Unicode people. >>>> >>>> >>>> >>> Let's not get into Unihan flamewar. There are other problems with other >>> languages which are more serious. Here are few of them: >>> 1) combining diacritics. >>> 2) ligatures. Important for indic languages >>> 3) context variants. Important for Arabic writing system. >>> 4) bidi. Important for Hebrew and Arabic writing system. >>> >>> Generally current gfxterm is pretty much unsuited for any of these 4 >>> problems. And gotoxy is pretty ambiguous in bidi context >>> Few useful links: >>> http://en.wikipedia.org/wiki/Help:Multilingual_support >>> http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Unicode/Test/arabe >>> >>> >> >> Not being able to use combining diacritics sucks. Does that mean that >> grub won't be able to draw decomposed Unicode strings? >> > I haven't checked. But I suppose it doesn't since it stores one > codepoint per on-screen place >> Either way the four points above are things that gfxterm simply does >> not support > It may need a major changes to support :( And these changes may > propagate through whole terminal system (gotoxy concept is flawed) >> whereas Unihan flamewars are inherent feature of Unicode >> > You seem have missed variant selectors > (last paragraph of > http://en.wikipedia.org/wiki/Unihan#Graphemes_versus_glyphs) > And we're back to multichar per on-screen place problem >> and the gfxterm technically should be able to display CJK languages >> given a good enough font. >> >> Also if worse comes to worst Indic, Arabic or Hebrew can be feasibly >> written in Latin, Chinese cannot. >> > pinyin. I know it's disagreable to read for native speakers, but it's > similar for Arabic.
show grub menu with pinyin? it is very very stupid. > In worst case we can just say Japanese people to install Japanese fonts > only and bear with Chinese having a bit wrong rendering and vice-versa. >> Thanks >> >> Michal >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> >> > > > -- > Regards > Vladimir 'φ-coder/phcoder' Serbinenko > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
