From: Vinod Kumar (rigvinod@gmail.com)
Date: Thu Mar 23 2006 - 04:48:05 CST
On 3/23/06, Peter Constable <petercon@microsoft.com> wrote:
> > Behalf Of Vinod Kumar
>
> > Reordering of glyphs within the font becomes necessary when the font
> > does not have some glyphs.
>
> Not so. The Indic shaping engine in Uniscribe has been updated to
> accommodate variations in re-ordering based on the nature of the glyph
> substitutions in the font. The recommendations for Indic OpenType font
> implementations is in process of being updated to reflect the changes.
>
If Uniscribe chooses to implement a shaping pipeline with back and forth
interaction between the stages (char level reordering <-> font ),
multi pass substitutions with the OpenType font using myriad Feature flags
it should be understood as Microsoft Indic OpenType recommendations.
The IndiX Indic OpenType implementations are able to convert a character
syllable (in visual order) to appropriate glyphs from the OpenType
font in a single pass without any Feature flags and no back and forth
interaction. This is possible because Indic script shaping can be
expressed as productions from a Context Sensitive grammar. The OpenType
substitution tables appear to be implementations of such productions.
This is what Philippe Verdy means when he says:
"A generic OpentType font renderer can then be used even for complex scripts
that it even does not know, and for which no script-specific features are
recognized and treated specially."
On Mar 17, 2006 4:00 PM, Antoine Leca said:
"When it comes about Indic scripts rendering, there is another (industrial)
"Standard" which is much more relevant, it is the Open Type specifications."
In TUS, Indic script rendering should better be described using a formal grammar,
maybe Context Sensitive, but possibly Context Free. Formal grammars are not
new to TUS. TUS has used Regular Expressions in Annexe #29 Text Boundaries.
From such a specification, Uniscribe or any other software
can implement the shaping according to their layering architecture, font model and interfaces.
TUS for Indic script rendering with the least powerful grammar will also
show up people who use a sledge-hammer to break a nut.
AAT is based on (Extended) Finite state machines and corresponds to (Extended?)
Regular expressions. AAT appears to be much more compact and efficient.
The formal model behind OpenType is probably Context Sensitive grammar.
But implementors get so immersed into the OT technology to believe and proclaim
that a Half Ka Glyph appears in the rendering of Devanagari text because
a stupid flag called HALF is set!
Microsoft Indic OpenType recommendations should not be the
standard for Indic text rendering.
A pioneer can be excused of following round about tortuous paths. But it is
up to ohers to imbibe what the pioneer has shown, straighten the paths,
and simplify the walk. Microsoft and Adobe
introduced OpenType for complex scripts (Bless them). But abstract, improve and progress
from their example as well as that from Apple, TeX and many other complex script shaping
solutions.
> OpenType Layout tables were not designed to support re-ordering, and that
> should not be attempted in the font. Font implementers should follow the
> OpenType font recommendations -- these should be treated like a standardized
> API: interoperability is built on having implementations working from the
> same assumptions.
>
> Peter Constable
>
>
When a font table implementor reorders the glyphs with lot of pain, she
is not breaking the OpenType specs or introducing new ones. Recently
there was some addition to Volt wherein existing capability was made available
with a simpler interface. Similarly Volt (a tool from Microsoft for creating
OpenType tables) can support tables with reordering. This will not need extensions
to the OpenType specs.
When she reorders glyphs in the font, she is breaking the recommendations
of the shaping pipeline of Uniscribe. An API like that of Uniscribe is interoperable
within it with complexity moved from font layer to the character level and its tortuous
interaction with the lower font layer.
But others like IndiX have other set of API. The design criteria we try to follow
are 1) back and forth interaction should be avoided if possible 2) interaction should
not specify more than what is minimally necessary 3) a problem arising at a layer
should be solved at the layer itself.
It would be nice if third party components like an OpenType Indic font have a standard.
Microsoft has not released that standard but it can be inferred from the interface that they
specified. The initial interface specifications indicated a one pass architecture with
substitution tables tagged with specific Feature flags like HALF. But down the line, with
other scripts, the field got muddled. That is why TUS should specify the Indic text
rendering formally, with a Context Sensitive grammar. A font designed by Philippe Verdy or IndiX would be much more closer to such a standard.
Vinod Kumar
-- पृथिवी सस्यशालिनी Prithivi Sasyashalini
This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 04:50:39 CST