> Let me give a proper example this time. Consider a "Vowel Sign E" [U+0947]
> appearing after any non-consonant character. This sign is generally
> attached to the consonants. It has zero advance width with negative left
> side bearing in the font. 

Ok.

> Clearly, since in this case the sign is not
> preceded by any consonant base, it has to be rendered using one of the
> mechanisms specified in fallback rendering of non-spacing marks.

If it is preceded by a SPACE (or is first in a string/paragraph/similar)
it should be rendered as a "freestanding" glyph (no dotted circle).  If it
is preceded, in the source string, by, say, FULL STOP, a typographically
acceptable rendering would be to have the vowel sign E glyph float on
top of the glyph for the FULL STOP (no dotted circle).  Similarly for a
vowel sign E that follows a LATIN CAPITAL LETTER A. (But I don't expect
good positioning, just readable.) Again similarly, a vowel sign I that
follows an EQUAL SIGN should be rendered as a vowel sign I glyph to the
left of an EQUAL SIGN glyph.  No dotted circle. (I know that the reordrant
vowel signs may reorder over more than the preceding base character IF it
is a (sub)string in an Indic script.) Again similarly, a <KA, II, II>
string should be rendered as a KA + II + II glyph sequence (invoking
any ligature for KA + II if there is one in the font; II + II is
unlikely to have any ligature, since it is not used by any orthography). 
No dotted circle(s). The fallback hinted at in TUS 3.0 that uses dotted
circles is 1) typographically horrible, and 2) cannot indicate that
there is any error in the given character sequence.

...
> the application. Now in order to render it with dotted circle if we
> introduce the circle in the text before this sign then also 
> the circle is invalid base for this "Vowel Sign E".

No base character is invalid for any combining character.

...
> > Languages or syllable boundaries have nothing to do with this. These
> > special
> > sequences should *never* be part of any syllable or word in any language:
> > they are just a way of showing the shape of a glyph, to be used when,
> > e.g., talking about typography or spelling.
> 
> Then how can we rake care of fallback mechanism?

By removing that particular fallback mechanism from implementations
as well as the TUS text!  (I'm serious!) This particular fallback
mechanism is NOT recommended as it stands.  But since its mention is
erroneously taken as a recommendation, I'd suggest removing also its
mention.  That mechanism is as bad as misplacing glyphs for combining
marks on the glyph(s) for the follow-on character, if not worse.
("Show invisibles" (for all of the text or a "user" selected run
of the text) is an entirely different story.)

                /Kent K


Reply via email to