> Well, for those platforms for which the entirety of glib2 has > been ported - which as far as I know is....Linux, Linux and Linux.
And win32, beos, and macosx. > >and is an abstraction that will use > >Uniscribe on Windows and ATSUI on Mac as well as > >FreeType on *nix. > > Not as I understand it. It will simply use FT2 - it does NOT > try to sit on top of UniScribe or ATSUI...nor why should it since > most of that logic is higher up in Pango. Pango is not an abstraction of UNISCRIBE or ATSUI. It is its own implementation of similar services. > True, you'd need to add the appropriate glyph shapers, > contextual handlers, etc. Tomas has already done a nice job of that > with Hebrew and Arabic, and if/when we get users who are itching for > Thai and Indian, we can add shapers for those too. Pango is also a *Hell* of a lot more than just freetype. There needs to be a *lot* more work done than what Tomas has already done, and this sort of thing is very hard to get right. In my opinion, if we don't use UNISCRIBE or PANGO or ATSUI or something similar, our plans for full internationalization is doomed before it starts. > >I think the major argument we had against Pango was > >that it requires glib > > Right! I'd rather port a threading interface from GLIB to platform XYZ than redesign Pango. Plus this means that more people will get to use our work from GLib. Let's prioritize here, people. Fixing a makefile or coding one well-defined function is easy. Coding an entire internationalization/localization platform is billions of orders of magnitude harder. Dom
signature.asc
Description: This is a digitally signed message part
