> Andrew Dunbar: > Does it actually render all 5 characters into the one > character cell or does it need to map them to a > precomposed character? It lays the 5 characters over each other.
> Cool! Does it support the Arabic vowels? No, I have no knowledge of Arabic, the only stuff I implemented is the consonant shaping and support for 2-char ligatures. I would love to do more, but it is beyond my abilities. > Maybe Syriac. Unfortunately, Syriac is defined purely semantically in Unicode, the shaping is delegated to font renderers, which is one reason why we really need OpenType support. > Greek has a final form for Sigma but I > read somewhere that this is usually handled specially. The Greek data is in the tables, but I have no idea what a Greek user expects. (I got into trouble because of automatic shaping for Hebrew; the normal Israeli user does not expect that, so I had to add a checkbox into preferences and it is off by default). > Indian scripts don't care about position but have > extremely complex ligature requirements. We could improve the ligature support, but that may not be the best the way to go. We will need to use a 3-rd party renderer for all of this stuff sooner or later. > I think these font problems are going to become a more > prominent problem the further we get. I think you are right. That's one reason why I am so keen to migrate to FreeType, for that should at least make things easier. > We need to push for Hebrew, Arabic, Thai and Indian > language users - or at least testers! Especially the > first two since they work pretty good on the current > AbiWord - we should really make a special effort to > announce AbiWord 1.0 on Hebrew and Arabic Linux and/or > free software sites if they exist. I have been trying. There are quite a few Hebrew testers involved now, and it is working fairly satisfactory. Folk from the Arabeyes.org project expressed interest recently, and hopefully we will get some contributions from them. There is though another problem. The Hebrew-speaking folk are interested in Hebrew, which means their interest stops largely at the level of Fribidi functionality. The Arabeyes folk are interested in Arabic, planning to produce shaping engine for Arabic that could be used alongside fribidi. For me the scope is too limited. I would be happy to plug in 3rd party Arabic shaping engine, but ultimately I want more than that. In long run, Pango (or something like it) is the answer, it certainly has got the vision, but even in the medium run, I would like to be able to do more, to support any language that has line-based layout and for which the shaping can be done via the Unicode codepoints. > > Consequently, I want us to migrate to FreeType ASAP. > > This will give us a level playing field on all platforms, and > > rid us of huge problems on Unix and the serious difficulties caused > > by inconsistent behaviour of the myriad of Windows. > > This means Xft on X too, right? No, FreeType is independent of any system font mechanism; it parses the font files and gives you the glyphs as bitmaps. > > As far as Pango is concerned, apart from the > > portability problems, from what I have seen, its API would make it very > > difficult to integrate with the existing layout engine. My > > Can you give us some concrete, technical examples? > Please CC the GTK I18N list too so we can get comments > straight from the Pango guys. No, I cannot :). But as far as I understand, Pango is a fairly high level formatter, it does something like our fl_BlockLayout class, and we would have to replace the blockLayout with it _to_get_most_out_of_it_. This basically means throwing our entire existing layout engine out and start again. It could well be the best thing to do right now, but I am not fully convinced. > I'm under the impression that using Pango will make > exotic languages "just work" in places such as > dialogs and widgets too. We might handle the rendering > nicely on screen but can we handle it in say the > spellchecker window or in window title bars? I am not sure that is the case; what we can do with the widgets depends on what the widgets can do, and that varies from OS to OS. But this is a real issue we will have to address as well. > Again please tell us what Pango is missing for us specifically. I am not saying Pango is missing anything, I am merely not sure that the folk who advocate using Pango have strayed past the Pango home page. It is about time that someone undertook as serious feasibility study of using Pango. > Surely we would use Pango only for rendering the > straight "runs" of text. All formatting including > tabs we would do ourselves. If that is all we want to use Pango for, then we have to migrate to freetype first, because we will be left to do the screen drawing using glyph indices, and we do not want to do this in platform specific code, because that would mean having the whole shaping system in platform specific code, since the indices are system- dependent. Also, no-one should assume that this is trivial, to quote from the Pango docs: "While complete access to the layout capabilities of Pango is provided using the detailed interfaces for itemization and shaping, using that functionality directly involves writing a fairly large amount of code." > Surely if pango can give us a shape > to print on the screen it can give us one to print on > a printer - but I don't know printers alas... Pango, if used in the way you envisage, only gives us a glyph indices, but even if it gave us actual shapes, this would be of no use for generating PostScrip. In the Unix World the fact we can draw it on screen does not mean we can print it via PostScript, because we could well be using non-PostScript fonts on the screen. Again, I am not saying there is a problem, merely that this issue has to be looked into, for being able to support a myriad of languages on screen is not enough in itself. Just for the record, I am _not_ objecting to us using Pango, neither for low-level shaping, nor for high level layout. I am objecting to deciding to use Pango without thinking seriously through what would be involved, what it would bring us, and *WHO WILL DO THE CODING*. The bidi experience taught me that not that many people will do the coding when it comes to more "exotic" internationalization. Even in its most reduced form, the migration to Pango would require serious commitment from the entire development team, without it we should stop even talking about it right now. As for me, I am entirely convinced that we will have to migrate to using a 3rd party layout engine sooner or later, and if Pango is the best choice, let's use it. Tomas
