From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Tue Aug 23 2005 - 02:51:38 CDT
On Tuesday, August 22nd, 2005 22:20Z Philippe Verdy wrote:
> How can an OpenType Layout processor correctly reorder glyphs,
Short answer: it can't.
One problem inherent of the OpenType idea of dealing with Indic scripts is
that the job to reordering the _glyphs_ is under control of the
"application" (i.e. the rendering engine, Uniscribe and its concurrents),
without knowledge nor information from part of the font other than the
mapping from Unicode codepoints to glyphs. OTOH the encoding can control
part of the process through use of the joiners.
First, this creates a pretty heavy workload onto the engine, to deal with
the corner case, particularly for the scripts (like Tamil) which reorder the
left-standing matras to the left of the base consonant, while the process is
thought toward helping formation of maximally ligatured conjuncts.
Then, it put the whole idea at the mercy of the correctness of the initial
analysis of the engine writers. For example, we had a discussion several
months ago about Devanagari, in the (rare) case where the resulting base
glyph of the conjunct does not contain all the consonants (the typical
example were TT.TTH.I ṭṭha <U+091F, U+094D, U+0920, U+093F> ट्ठि, when the
ट्ठ is lacking in the font): we find printings where the rendering looks
like ट्ठि, but were not able to find the other possibility (with the
i-matra at the extreme left), even if it is what is specified and
implemented in the OpenType rendering engines...
> So all these leave me very perplex about the portability of fonts
> across systems (and I feat the Uniscribe only works reliably by
> detecting a few fonts made or accepted by Microsoft only, and whose
> names would be internally hardwired in Uniscribe).
You are free to fear. However current practice shows that (enthousiastic)
designers with few if any programmatic habilities, and certainly not MS
blessing, are able to produce fonts that happen to work more or less
reliably with the various versions of Uniscribe and its concurrents. Of
course, there are always corner cases where it does not work (and the
culprit turns to be either the font or the engine), but at least the process
output is not virgin.
> This may explain why some scripts can't work on all
> versions of Windows,
Well, let's be realistic. Uniscribe was introduced in Windows as part of IE5
for Win9x (including 98SE "gold"). Indic support was present from day one.
Still, you would be very lucky if you succeed to render any Indic script on
bare 98SE, even if you add fonts.
I stopped counting the versions of Uniscribe I have seen; they always had a
increased degree of support for the Indic scripts; but there are still areas
of lacking support, and even the current betas of Vista are lacking things
(for example, Malayalam, since the status of the rendering of some
characters is still undecided!)
> and that fonts working with Uniscribe are severely
> tied to Uniscribe's implementation
That is misleading. OpenType for Indic is a emerging standard, not yet
stabilized (partly because the very rendering of Indic scripts encoded in
Unicode is still fuzzy, as I explained), and Uniscirbe is the reference
implementation. To put it blunty, a font that does not work with current
versions of Uniscribe is probably not complying with the standard as it
stands now. OTOH, the other engines tries to support the same set of
specifications, and hence are able to render the same fonts. When a font can
be rendered with Uniscribe but not with the others, there is generally a
point made in the relevant forums, and the relevant parties agree to the
correct behaviour; and no, it is NOT always diced out in favour of
Uniscribe.
> (or even worse, its version...).
See above. You are on bleding edge technology...
Antoine
This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 02:52:46 CDT