It looks like a good idea... I've some time available for now (the company I was working for just went bankrupt and closed...). I'm participating in a project for language processing, currently working with chinese, we know the problem of character rendering... My main skills are OO programming in C++, also some Java. I have some experience in unix/linux programming gcc, gnu autotools... If there are more people interested on this, please step forward...!
--- Gaspar Sinai <[EMAIL PROTECTED]> wrote: > 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/ > ===== Pedro Ferreira Grenoble - France "Everything should be made as simple as possible, but not simpler." - Einstein __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
