Hi, I have a new redering schema in mind, that I am going to implement in a future version of Yudit.
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. 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. ② 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. ③ OpenType is not an Open Standard. ④ Rendering is a non-reversible process The idea is: Ⅰ. Assign codes and hot spots for all possible Glyph componenents, per script, per language system. Ⅱ. 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. Ⅳ. Create bitmap and vector fonts. The glyph codepoints are defined in (Ⅰ.) so this will be an easy process. Much easier than creating OpenType tables. Ⅴ. 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. Ⅶ. 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 - Rendering is linear and needs very littel processing power. - It is testable - It is bitmap-font-friendly - 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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
