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

> > Who asked for it, and whether a spec is Unicode compliant or not, are
> > two different issues. Regardless of who asked for it, if we remove the
> > option, CSS will be incompliant.
> >
> > I think John is in agreement on this point; he's not agreeing with the
> > importance of Unicode compliance because it's informative, and the
> > definition is not good, if I understand correctly. It's first time in
> > this discussion that someone is not agree on that point.
> > What makes you think that way?
> 
> I'm completely baffled how you can make this statement.  In my opinion, there is *no*
> compliance issue here.  UTR50 defines an informative property and states *very* clearly
> that higher-level protocols define actual usage.

Ok, I misunderstood your statement, I apologize. I don't agree with you though. A spec is informative does not mean there's no compliance issue, and I think you misunderstand "higher-level" sentence, but that's not the topic to discuss here. Anyway, I didn't tried to mislead but I may have looked so, sorry about that.


> In private communication with other members of the UTC, I don't think that the UTC meant
> to impose on users of UTR50 that they exercise the fallback of Tr. Reading over UTR50, I
> certainly don't see any such normative requirement.  This sort of fallback is *possible* for
> Tr codepoints but saying that it's normatively required by UTR50 is at odds with the actual
> wording in UTR50.

This is really about the spec and UTC, nothing to do with CSS; this discussion should happen in Unicode ML, please.


> The common practice used by fonts and layout engines supporting vertical text layout has
> been to support the proper display of Tu and Tr codepoints via the use of vertical alternates.
> If we're going to normatively require what is effectively OpenType feature fallback for only
> Tr codepoints, we definitely need to justify that in terms of actual use cases that it solves.
> It seems far better to treat the lack of vertical alternates for Tu and Tr codepoints as a font
> bug rather than burden layout engines with complex fallback schemes.

No, we do not require the behavior. We agreed and changed the spec to allow it over a year ago, so this discussion is done. Do I still miss something?


> Unless there's stronger justification for the optional fallback scheme you've described, I
> think we should resolve to omit it entirely.
> Omitting fallback in no way affects any form of compliance with Unicode.

I can't connect previous paragraph and this paragraph. Yes, we agreed and spec updated to allow your proposed behavior over a year ago. Now you're asking to omit the Unicode-defined behavior. I do not understand how these two connect to each other.

This is the point of discussion, right?

You want to reject one optional behavior currently in the spec. James and I in this ML are against. Murakami-san was against as well if I remember correctly. Can you explain why you think we should reject the behavior?

/koji

Received on Wednesday, 2 October 2013 11:26:41 UTC