Re: Too Many CTL Layout Engines [WAS: Concern with Burmese script]

["Edward H. Trager" <ehtrager umich edu>]

On Saturday 2004.12.04 11:06:57 +0000, Simos Xenitellis wrote:
> Στις 04/Δεκ/2004, ημέρα Σάββατο και ώρα 04:08, ο/η Maung TunTunLwin
> έγραψε:
> > >> Also what about Burmese? Is anyone working on Burmese via
> > >> OpenType, or does Burmese really require SIL's Graphite, and if
> > >> so is anybody seriously working on SIL integration into Pango?
> > > I think it should be quite possible to do Burmese with OpenType,
> > > I'm not aware of anybody working on that, or on Pango support
> > > for Burmese OpenType fonts.
> > > For Graphite support, see:
> > > http://bugzilla.gnome.org/show_bug.cgi?id=135697
> > > There are some unresolved issues with font selection that make
> > > this unlikely for Pango-1.8.0.
> > 
> > Burmese/Myanmar script support is added to m17n library.
> > See http://www.m17n.org
> > That use only TTF and not fully functional.

For human languages, any software component that is "not fully functional" is 
equivalent to "useless" (although it may be a good starting place for the 
developers).  Please note that I am not being critical here, just realistic.

> > 
> > Really, I intended to work on OTF font but it will take time. I have many
> > progress on determining reposition glyph and wording breaking and fall back
> > renderings. I also willing to work with somebody who can help me on pango.

Although the following point is a bit of a tangent, it is a very important issue
that all Open Source developers interested in Complex Text Layout (CTL) script
issues should think about:  In the Windows World, there is Uniscribe and that
is it.  On Mac OS X, there is AAT.  

But in Linux there is (1) Pango, (2) ICU's
layout engine which is used by OpenOffice on Linux (OpenOffice uses Uniscribe on
Windows), (3) Whatever QT has for CTL which is used by KDE and finally I suppose
one has also to consider (4) Graphite which supposedly provides some advantages
for complex scripts like Myanmar which the developers at SIL felt OpenType did
not provide, or did not provide correctly.  And Oh, I almost forgot, there is
also (5) Mozilla/Firefox/Gecko with its own stripped-down or souped-up (I'm not really 
which it is) version of embedded Pango.  And finally I really should not forget
(6) Yudit which has all of its own layout code but really works well for some
scripts where either Pango or QT hasn't (or at least in the recent past had not
yet) caught up.

So, roughly speaking, Open Source developers have somewhere between twice
as much work (if we only look at, say, Gnome and KDE) to four, five, or six
times as much work.  Well, yes, of course somebody working on Pango could peek
at what ICU does, and vice-versa.  But surely you see my basic point.

Does anyone else on this list think that this is a mess?
There really should be a combined development effort to produce a
really fine complex text layout engine library that everyone (KDE, Gnome,
ICU, Open Office, etc.) could use.  Just as there is only one FreeType2 library.
Everyone uses FreeType2.  So why isn't there just one CTL layout engine?

Probably the current state of affairs just highlights the extent to which
Open Source development works like an evolutionary system - a lot of diversity
appears initially, just like in the Burgess Shale, and then later it gets
winnowed out as the principal of "survival of the fittest (code)" comes into
play over time.

If that is how it works, that is fine.  Now would be a good time to hasten the
evolution of Linux and Open Source software.  Of the available Open Source 
CTL layout engines, can someone with true knowledge about this stuff unbiasedly
tell me which is the "best" general-purpose CTL layout engine available? 
Is it ICU's? QT's? or Pango?  Please be sure to tell me why you think so.
Email me off-list if you think your opinion will generate political squabbling
between the pro-Gnome vs. pro-KDE camps.
Also, if others (maybe the FreeDesktop.org folks?) have alreadly been discussing
this problem, please excuse my ignorance and let me know about it.  I am
very interested in understanding this issue.  Wouldn't it be nice
to see universal high-quality support in Linux for all scripts supported in Unicode 4.0
by the end of next year, 2005?

> 
> Is there linguistic similarity between Burmese and another language (of
> the region)?
> Is Burmese so different to require "work from scratch", if I understand
> it?

Burmese ("Myanmar" is now preferred) is an Indic-derived script derived
from a South Indian script used for the Mon language.  The script therefore
shares many of the features of scripts like Devanagari.  I doubt that any
"work from scratch" is required.  But I think one does have to understand
how to implement a shaping module in Pango.  If one understands how the
Indic shaping module has been implemented in Pango, I'm sure that is probably
70% of the battle.  

Still Myanmar and Khmer may be different enough from
other Indic scripts to require separate shaper modules (i.e., not unified
into the Indic shaper module).  I don't really know enough about it.  Probably
Owen Taylor can tell us: Owen, is the plan going to be to integrate Khmer
and Burmese into the Indic shaper or should each have its own shaper code?


> 
> simos
> 
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> 
>