From: Keyur Shroff (email@example.com)
Date: Fri Jan 31 2003 - 03:02:26 EST
--- Kent Karlsson <firstname.lastname@example.org> wrote:
> > 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
> 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).
No fallback rendering is coming into picture with your explanation.
> > I add that this is a good way of displaying a combining mark that has
> > base character, i.e. one occurring at the begin of a line or paragraph.
> No, those should be displayed *as if* preceded by a SPACE (TUS 3.0 page
Now here you are really talking about fallback rendering :-).
Here is the para you are talking about.
"In a degenerate case, a nonspacing marks occurs as the first character in
the text or is separated from its base character by a line separator,
paragraph separator, ot other formatting character that causes a positional
separation. This result is called a defective combining character sequence
(see chapter 3.5, Combinations). Defective combining character sequences
should be rendered as if they had a space as a base character."
In the text there is no mention of explicitly inputting space character
before any combining mark that is defective combining character. Also, the
word "should be rendered" implies that it is recommendation.
> > 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.
Note that the text has been written in the section "Implementation
Guidelines". Can't it be considered as recommendation? (although not
necessary for implementation)
> But since its mention is erroneously taken as a recommendation, I'd
> suggest removing also its mention.
This is disastrous! What will happen to the systems which already
implemented this recommendations!? Will they be considered invalid
implementation afterwards? What is about stability?
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
This archive was generated by hypermail 2.1.5 : Fri Jan 31 2003 - 03:45:33 EST