Re: [css3-writing-modes] Re-Summary of Tr in UTR#50 and text-orientation discussions

Hello,

It looks like a long-term/short-term discussion.

I'd like to share my two story about Traditional Chinese about UTR#50.

First, about fullwidth semicolon: 嚗�(U+FF1B)

When in vertical writing, fullwidth semicolon should be upright in Chinese, and rotate in Japanese.

Then, a problem happened. Apple prematurely implied UTR#50 rev 6 spec into their webkit. So every 

fullwidth semicolon in vertical writing are rotate. I have to assign text-orientation: upright to let all of them

be upright to fulfill Traditional Chinese layout requirement. 

But another problem happened. Semicolon is part of punctuations that are prohibited to appear on line start.

After I marked all of them, they would break the rule. Is there any solution to manually fix it? I've reported this bug.

Further, Google 's reading system add unnecessary whitespace before/after the semicolon. Another bug reported.

Second, about fullwidth tilde: 嚚�(U+FF5E)

Just like wavy dash in Japanese, it's frequently used punctuation in Traditional Chinese.

When in vertical writing, fullwidth tilde should be rotate.

I've cross-tested text-orientation: sideway and various fonts. (with -webkit prefix and several combination)

I cannot see the result I want, even cannot figure out the problem is UA implementation or font's issue.

That' my stories.

So my viewpoints are :

#1, We don't need fall-back neither sideway nor upright. What I should do is asking font foundry and OS/UA vender to 

fix their font or system to fit UTR #50. It may take long time, but ideal.

#2, Let sideway and upright as MUST/MUST. Author could fully control their content's layout. There should be lots of 

problems happen (just like line-start prohibition one). But we can make our contents/ebooks fixed sooner.

#2 is better. Because fonts/UA fix is difficult for me (or should I say, for Taiwan/Traditional Chinese?)

Regards

Bobby Tung



MURATA Makoto <eb2m-mrt@asahi-net.or.jp> ��� 2013/10/15 銝����1:51 撖恍��嚗�

> John,
> 
> 2013/10/15 John Daggett <jdaggett@mozilla.com>
> 
> Makoto Murata wrote:
> 
> > I have been wondering whether this debate is about factual
> > matters or subjective value judgement.  Here is my (rough)
> > understanding of John's argument.
> >
> > (1) Since implementation costs are heavy, even optional
> >     fallback should be disallowed.
> 
> No, my point is that it's simply *unnecessary* in the context of
> OpenType fonts that supply vertical alternates for nearly all Tr
> codepoints.  This is based on looking at actual fonts rather than
> abstract notions of whether fallback is beneficial or not.  The only
> thing that's subjective is whether one takes the viewpoint that
> this fallback is beneficial even if it only affects a handful of
> codepoints in practice.
> 
> So, your argument is not strongly based on implementation costs
> but rather based on real benefits.  You think that fallback is not 
> beneficial since it only affects a handful of codepoints in practice.  
> Apparently, Koji thinks otherwise.  As you said, this is clearly a 
> subjective issue.  I guess that further discussions will probably go
> nowhere, and start to wonder whether the CSS WG is willing to 
> vote soon.  To me, further delay of writing modes is much 
> worse than anything else.
>  
> Regards,
> Makoto
> 
> 
> > (2) Fallback lead to negative side effects.
> 
> > (3) Optional fallback confuse authors.
> 
> Optional fallback leads to differences in behavior across user agents
> with the same fonts.  For U or R codepoints, when the default
> orientation is not what an author desires, they'll see that it isn't
> correct and use markup to adjust it.  They won't always see this for
> Tr codepoints because the behavior will vary
> across user agents.  Having incorrect behavior for a small set of
> codepoints is not beneficial to users; explicit markup assures that
> it's correct.
> 
> In short, existing practice is that the transformation required for Tu
> and Tr codepoints is handled via an OpenType feature.  For situations
> where a font is missing vertical alternates for Tu and Tr codepoints,
> a better made font can be used or, in the case of Tr codepoints,
> explicit markup can be used.
> 
> Down the road, as fonts standardize the set of alternates they provide
> based on UTR50, there will be no need for this fallback feature and
> this entire discussion will be moot.
> 
> Regards,
> 
> John Daggett
> 
> 
> 
> -- 
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto