From: John Hudson (tiro@tiro.com)
Date: Tue Aug 23 2005 - 15:39:29 CDT
Antoine Leca wrote:
> 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.
While this description is accurate, I'll point out the ways in which this is not a
'problem', but a sensible trade-off.
> 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.
The converse would be a very heavy workload for the font and for font developers. This is
the approach taken by AAT and Graphite (although the latter at least has the benefit of a
relatively simple development language), and one only has to compare the quantity of
OpenType fonts in existence to the quantity of AAT or Graphite fonts to understand why the
OpenType approach might be considered a reasonable one. Part of the reason for the
relative market success of OpenType compared to AAT or Graphite is of course due to the
fact that it is supported in several very major applications. But you shouldn't
underestimate the degree to which the difficulty of AAT development has been a problem for
more than a decade now. Most font producers are software developers only in the most basic
sense of the word: they are designers, not programmers, used to working with visual
drawing tools not state tables. Microsoft and Adobe very sensibly realised that they
couldn't expect font developers to be responsible for the heavy lifting of language and
script support.
Further, the OpenType lookup model is relatively slow in terms of processing time,
compared to the state table/engine model used in AAT and Graphite. Character level
handling of things like re-ordering, string analysis, canonical composition/decomposition
is very much faster than using OpenType GSUB lookups.
> Then, it put the whole idea at the mercy of the correctness of the initial
> analysis of the engine writers.
Yes, although it is easier to fix a bug in one shaping engine than it is to fix a bug in
hundreds of fonts.
I agree with the remainder of your letter, especially your point about OpenType for Indic
scripts being an emerging standard.
John Hudson
-- Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com
This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 15:40:21 CDT