From: Edward H. Trager (email@example.com)
Date: Thu Aug 25 2005 - 12:30:18 CDT
On Thursday 2005.08.25 01:42:25 +0200, Adam Twardoch wrote:
> Christopher Fynn wrote:
> >If one wants to Microsoft's shaping engine (Uniscribe) for a
> >particular script then that script has to be already supported (or one
> >has to wait for Microsoft to add support) - and, in the font, one has
> >to use lookups only under the particular sub-set of OT features
> >Uniscribe actually supports for that script.
> >For unsupported scripts, applying OT shaping to PUA characters and so
> >on in MS Windows there aren't many choices: 1) Try to find an
> >application supporting a font and shaping system where you can put all
> >the necessary logic into the font tables (GRAPHITE, AAT) and use
> >that. 2) Find an application using an open source OpenType shaping
> >engine (like Pango or ICU) and add your own code to enable shaping
> >support for the script / characters you need. 3) Wait for Microsoft to
> >add support for your script in Uniscribe.
> The real problem is: even if the IndiX, Pango and ICU developers got
The Indix that one can download from TDIL (http://tdil.mit.gov.in/download/INDIX.htm)
is still based on GTK+1.2x whereas
current versions of the GTK+ toolkit are somewhere around 2.4x. The fact that
Indix appears to not be synchonizing their code to keep pace with the rest of
the Linux world (or at least rest of the Linux Gnome/GTK world) makes me think that Indix
is not going to materialize as a long-term solution in India or anywhere else.
Besides Pango and ICU, you neglect to mention M17N (http://www.m17n.org/).
Also my understanding is that the Pango and ICU developers do in fact communicate
to insure, for example, that improvements in Indic script rendering make it
into both the Pango and ICU code bases. It would be better though if they unified
their efforts into a single library for text layout. Also, it might help if the Pango
and ICU developers took a close look at what the M17N developers have done (For example
M17N has support for Myanmar layout which, when I last checked, Pango and ICU still
lacked). My understanding is that with M17N it is possible to add
new shaping rules for scripts without having to recompile the whole M17N library.
Unfortunately, I haven't had time to look at the details nor evaluate if this
kind of convenience results in a performance penalty or not.
> together and specified shaping rules for writing systems not supported
> by Uniscribe, such an effort would be doomed because, should Microsoft
I don't believe such an effort would be "doomed" (to use your choice of words).
The GTK+ toolkit (with Pango for text rendering) has already been ported to
Windows, thus opening a number of very good Open Source applications to use
by users of Microsoft operating systems. And do not forget that OpenOffice
uses ICU's layout engine.
The problem in my mind is that the vast majority of people continue to expect
commercial software vendors to provide them with solutions to their problems
in a timely manner. The reality, depending on what problem you want
solved, is that the commercial software vendors are not necessarily going to
solve it for you in the kind of time frame that you want, if they choose to
solve it at all.
On the other hand,
the current state of Open Source is also not as encouraging as it could be: I can think of at
least six projects that aim, to one degree or another, to provide text layout
services for complex text layout scripts:
Pango, ICU, M17N, Indix, Graphite, and --don't forget-- FreeType Layout
(http://freetype.fis.uniroma2.it/ftlayout/ , still vaporware I think). Trolltech's
QT Open Source framework also has complex text layout (so that would be seven).
And I probably should not forget Mozilla Firefox (which uses something called
"Pango Lite" on non-MS platforms but Uniscribe on MS platforms), so that's eight.
For complex Indic- and
Indic-derived scripts, I would not be surprised if everyone of these libraries had
at least a few bugs, and the bugs could be different for each one of them. Well,
that's the nature of "evolutionary" systems like Open Source!
The developers of all of these Open Source text layout/text rendering
projects (plus the Firefox developers) need to get together for a week-long meeting
to hash out a proposed standard, an API, and a library for dealing with text layout
once and for all. That library could, for example, be designed from day one to support
all of the OpenType features that should be supported while also perhaps supporting
Graphite and M17N features where it makes sense to do so.
- Ed Trager
> no guarantee they would follow that implementation. (Actually, one could
> even presume they would NOT follow it).
> Currently, there is an international character encoding standard
> (Unicode/ISO 10646) and there will soon be an international standard for
> digital glyph storage in a font format (with OpenType being
> standardized). However, the "glue" between these two is a proprietary
> Microsoft technology, with no proper submission process and unsufficient
> resources within the Microsoft Typography group.
This archive was generated by hypermail 2.1.5 : Thu Aug 25 2005 - 12:19:32 CDT