On Sunday 24 November 2002 06:22 pm, Gaspar Sinai wrote: > Hi, > I have a new redering schema in mind, that I am going to > implement in a future version of Yudit.
I'm going to request that you not do this. Please concentrate your efforts on Yudit, which is my editor of choice. Please consider using Pango or Graphite instead. At least talk to the developers about the issues they see in implementing a rendering engine and modifying the OpenType format. Graphite Web: http://graphite.sil.org/, List: https://lists.sourceforge.net/lists/listinfo/silgraphite-devel Pango Web: http://www.pango.org (out of date) List: http://mail.gnome.org/mailman/listinfo/gtk-i18n-list > Of course it would take less than the estimated 10 years > of development time if someone, or some group would be > excited about it and implement it in a library. This is > the reason why I am writing down this here. > > More and more people are using Open Type fonts to render > Unicode text, I use it myself. Still, I think that Open Type > is not the answer to complex Unicode rendering. It is not yet the full answer, but the linguists at SIL are proposing extensions to OT for use with their Graphite engine. > The major problems with it are: > ① Very difficult to test the rendering software. Features, > need to be applied in a certain order. Even one mix-up will > result in bad rendering, and a very complex test should be > manually performed to catch the bug. Any rendering engine will be difficult to test, because of the complexity of the fundamental processes. If not OT features, the same capabilities have to be implemented some other way. > ② OpenType tables can not be shared between two fonts of the > same time, although similar positioning/substituting needs > to be performed. This makes the font file unnecessarily big. If this is a real issue, then we can devise a way to share the tables. I don't think it is an issue. Most fonts are well under 100K, except CJK. > ③ OpenType is not an Open Standard. Defining a new font format might be a good idea, if we can get the designers of font servers and rendering engines to agree on it. > ④ Rendering is a non-reversible process True regardless of the engine. > The idea is: > Ⅰ. Assign codes and hot spots for all possible Glyph componenents, > per script, per language system. Impossible. You can't predefine all glyphs for a language, much less for a script. The first counterexample to consider is Korean, where proper rendering has to reshape and reposition glyphs in a two-dimensional context. There are about 40 letters, each of which appears in hundreds of slight variations, and it is not difficult to make up syllables which would require new variations. Next consider Arabic-script languages, where the set of ligatures is language- and font-specific, and remains highly variable. Indic scripts have similar problems about the variety of ligatures. When stacking combining characters, whether multiply-accented Latin, math symbols, or Sanskrit written in the Tibetan alphabet, it has not proven possible to list all of the possibilities. Some of the positioning and shaping has to be done dynamically. > Ⅱ. Create a generic state machine thet can step through the input > unicode characters, and spit out Glyph components and their relative > hot spot positions. > Ⅲ. Create states and a dynamically loadable state table per script > per language system. Per font, in some scripts. > Ⅳ. Create bitmap and vector fonts. The glyph codepoints are > defined in (Ⅰ.) so this will be an easy process. Much easier > than creating OpenType tables. Exactly equivalent to creating OpenType tables. You just make fewer copies of the data (assuming availability of Free/Open Source fonts). > Ⅴ. Create a generic inverse state machine. The input is > components and their relative hot spot positions and the > output is unicode stream. > Ⅵ. Create dynamically loadable inverse state tables per script > per language system. Per font, in some writing systems. > Ⅶ. Use (Ⅱ) and pass it to (Ⅴ) to see if we get back out stream. > We can test the rendering engine on-the fly this way. > Ⅷ. Use (Ⅴ.) for OCR (character recognition) software to scan > text images into Unicode stream. > This is all - I am running out of Roman numerals ☺ > > The merits of such a rendering/font schema would be: > - Fonts do not need to carry extra extra tables Fewer copies, but not less data. > - Rendering is linear and needs very littel processing power. ?? > - It is testable > - It is bitmap-font-friendly I can't imagine it. How do you do adjustable glyphs in bitmaps? > - Once the specs are done, font making is an easy process. > > The drawback is: > - Need to fix the states for the script and laguage system. > This needs to be done very carefully. > > One thing is for sure: one man is not enough to implement all > this… > > Unfortunaltely I do not really have much time to discuss all > these steps and reasons now, so forgive me if I am not replying > my mails. > > G̳á̳s̳p̳á̳r̳ > > ガーシュパール・Гашпар・가스팔・Γασπαρ・גאשפאר > עברי 10-2*5 -- Edward Cherlin Generalist "A knot! Oh, do let me help to undo it!" --Alice in Wonderland -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
