En Gaspar Sinai va escriure: > > 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.
Either it is a font bug, or a rendering issue (Freetype showed us the former is more probable than the latter.) If the font fails with MS engine, there is no more problem! If if does not, either the problem is with your software, or it is with MS's software (again, both are possible.) And yes this is a problem, because this means you have to deal with what are basically MS bugs. Anyway, this approach gives you a point of reference. I.e. you are not alone in the dark (that is the position in which I saw the Omega project over the last 5 years, to give some example. Don't take me wrong: I believe Omega is probably a very good tool, done around very good bases. Alas, I cannot have any firm ideas on this, since I cannot get the whole picture of it.) > ② 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. True. From the beginning, TrueType files chose to be a bit weightier than its competitor (one of the big "disadvantage" against T1 back in 1989.) However, given the evolution of performances and bandwidth, I am not sure this is a mortal problem. Look, I am behind a 56K modem, partly because my phone bills are still lighter than a ADSL connection. However, I am looking around, and almost no binary package I am willingful to download are below the 1MB mark. And when it comes to rendering, what is really the fat are the CJKV fonts, where the OT tables do not represent anything important. > ③ OpenType is not an Open Standard. Very very true. This is even so that I suspect that part of the Uniscribe specs/functions (the part of OpenType that deals with Complex scripts, I mean) may be patented. I asked a couple of times this question to the Microsofties in the OpenType forum, and got no answer. :-(. > ④ Rendering is a non-reversible process > > The idea is: > Ⅰ. Assign codes and hot spots for all possible Glyph componenents, > per script, per language system. This is more work than the unfinished task of the AFII, which was collecting all the glyph forms. And at the rate Unicode is evolving, it appears a open work to me (that is not necessary a problem.) > Ⅱ. Create a generic state machine thet can step through the input > unicode characters, and spit out Glyph components and their relative > hot spot positions. Hey, this is GX, isn't it? > Ⅲ. 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. From experience: Creating OpenType tables is a *very* easy process (using e.g. VOLT) once you know what you are doing, i.e. - you have fully understand the OT spec relevant to the script - you have the full list of glyphs you want to show - you have the full list of intermediate glyphs you will need because of the rendering process For a Gurmukhi font, easy case I agree, it takes me about 2 hours, fully debugging included. For a Nagari font, I am still working on the list of conjuncts. However, a preliminary version worked in less than a day. And I did not copy Mangal, of course! > Ⅴ. 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. Well, here is the big gain for your idea. I have no idea about the state of Indic scripts OCR (I know some "things" are working), but this is certainly a good idea to follow. > The merits of such a rendering/font schema would be: > - Fonts do not need to carry extra extra tables I cannot agree. For example, in Nagari (Werner also cited the Urdu case), the ligature set appears really open-ended. And how can you handle the EUDC characters? > - Rendering is linear and needs very littel processing power. > - It is testable > - It is bitmap-font-friendly I am not sure you can't write OpenType font with only bitmaps. Anyway, I am sure Apple wrote GX'ified bitmaps fonts. > - Once the specs are done, font making is an easy process. Font making is an artistic process, not an industrial one (perhaps you should disregard Adobe to make this really true ;-).) I do not believe the industrial tasks associated today with font making, such as was hinting until last periods, or is still OpenType table creation, will not be displaced by future tools, easy to use to the font artists, and still availablke much sooner than your project, and compared to which VOLT will be seen as of ENEAC-era! However, I can be wrong here: font tools are slowly evolving, and the degree of piracy impedes profit, which in turn deter investment. > 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… Granted. Regards, Antoine -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
