RE: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

Ok, this time you're saying Tr is problematic, not cost v.s. value discussion.

This is not a mailing list to discuss how good or bad UTR#50 is. If you think it's problematic, please go to Unicode.

Two years ago, it was you who said CSS should not define code point level features, and we agreed that it should be defined in Unicode and we should just reference.

One year ago, UTR#50 was still so unstable that fantasai and I recommended to take a snapshot until it's stabilized, but it was you and Sylvain who strongly objected to it, saying CSS should just reference as is no matter in what state it is.

And now you're saying UTR#50 is bad that CSS should fork UTR#50 by changing one of its normative definitions. It is not a right way to fix issues, please try to fix Unicode.

I personally don't think your example is real at all, but that discussion should be done at Unicode ML.

/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Friday, September 27, 2013 10:05 AM
To: James Clark
Cc: Koji Ishii; W3C Style
Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'


> Complex case:
> 
>             cmap             feat1            vert             feat2
>   codepoint ====> glyph id A ====> glyph id B ====> glyph id C ====> glyph id D
> 
> In this case it's considerably harder to determine whether a given
> codepoint has a vertical alternate or not because of the influence of
> other features.  You'd need to actually determine where the 'vert'
> feature is applied and test at that point whether a substitution
> occurs or not.  Simply running the pipeline with and without 'vert'
> enabled isn't going to tell you that.
> 
> Another thing to point out here is that substitution rules in OpenType
> can be contextual.  A contextual substitution, for example, might
> require that gidA is transformed to gidB only when preceded by gidC or
> gidD.  So shaping characters in isolation isn't a good idea because it
> breaks the ability to use contextual shaping rules like this.

So I think it would help to consider an example to realize why manual
fallback for OpenType features is problematic.

For an online chat app, a Japanese font designer creates a font that
uses the discretionary ligatures feature ('dlig') to map punctuation
sequences to emoji glyphs [1]:

  ;)  ==> wink face

Since users in Japan often use an input method, they may sometimes
also enter the fullwidth equivalents of the ASCII punctuation
sequences above.  So the font designer includes substitution rules for
both the ASCII sequence and the equivalent full-width sequence,
described here using Adobe's feature file syntax [2]:

feature dlig {
  substitute semi_colon right_paren           by emojiWink;
  substitute full_semi_colon full_right_paren by emojiWink;
}

Assume that the font includes a vertical alternate for the full-width
right parenthesis (U+FF1A) but not for the full-width semi-colon (U+FF1B). 

Next, consider what happens when the user enters the text below and
the chat app renders it in vertically:

  素敵！；）

When discretionary ligatures are applied to this sequence, it should
appear as the author and font designer intended, with an emoji glyph
used for the final two characters.  For a user agent that doesn't implement
manual fallback for Tr codepoints, this is exactly what will happen.

However, if the user agent implements the optional "fallback to
rotated glyphs when vertical alternate not available", the user agent
will render the full-width semicolon by shaping it separately and
rotating it into place.  The intended emoji glyph will *not* be
displayed.

Manual fallback for features isn't simply an optional feature that
only "improves" the quality of vertical text rendering, it has the
potential to cause advanced feature usage to break.

Regards,

John Daggett

[1] interesting list of emoji sequences
http://www.jref.com/japan/culture/emoji.shtml


[2] Adobe feature file syntax
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html

Received on Friday, 27 September 2013 19:54:14 UTC