- From: John Daggett <jdaggett@mozilla.com>
- Date: Mon, 30 Sep 2013 19:09:25 -0700 (PDT)
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: Sylvain Galineau <galineau@adobe.com>, W3C Style <www-style@w3.org>
Koji Ishii wrote: > > Given the explicit lack of agreement that Unicode compliance is an > > issue I do not quite see how this could *possibly* be the point of > > discussion??? > > > > Or is 'Unicode compliance' the last-ditch argument to force your > > preferred solution in the absence of any actual implementor > > feedback? > > 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. 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. 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. 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. Current spec: http://dev.w3.org/csswg/css-writing-modes/#vertical-orientations # For Tr characters, which are intended to be either transformed or # rotated sideways, the UA may assume that appropriate glyphs for # upright typesetting are given in the font and render them upright; # alternately it may check for such glyphs first, and fall back to # typesetting them sideways if the appropriate glyphs are missing. Revised wording: # For Tr characters, the user agent should assume that appropriate # glyphs for upright typesetting are given in the font and render them # upright. Regards, John Daggett
Received on Tuesday, 1 October 2013 02:09:53 UTC