- From: John Daggett <jdaggett@mozilla.com>
- Date: Fri, 29 Jun 2012 02:00:57 -0700 (PDT)
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: www-style list <www-style@w3.org>
Koji Ishii wrote: > It's not a variation, it's a snapshot. It's true that fantasai and I > have a different table at wiki, and that there are a lot of > conversation going on, but the data in the ED is based on the draft > #5 plus only changes that were discussed with Eric and Microsoft. > It's not from our table on the wiki. I'm sorry if this wasn't clear, > I hope this clears some of the concerns you have. Neither fantasai > nor I have intention to use our ED/WD to influence UTR50 at all, and > we fully agree with you that doing so is really a bad idea. Then we should request another UTR50 draft containing the changes and use that. I am very strongly against defining something that looks like a delta on top of the UTR50 proposal. There is absolutely no reason to rush to publish something based on preliminary edits that have not necessarily converged to their final form. > > It would be much better for this part of the spec to define the > > behavior of 'mixed-right' and 'upright' given the specific values of > > the MVO/SVO properties defined in UTR50 (i.e. R, T, Tr, Tu, U). The > > spec contains the wording below but in an informative note that > > doesn't fully explain how the logic is to be used: > > : > > Proposed replacement: > > : > > I'm not sure if I understand your concern here very well, can you explain a bit more please? > > I hope you agreed to take a snapshot by now. Assuming so, is your concern: > > A. The definition of the derived properties is not normative. > B. The definition of the derived properties doesn't define what HO/VO are. > C. We should not make derived properties but use a snapshot of MVO and SVO directly. > D. Text is easier to understand than pseudo-code. > E. HO should not be used to define derived properties or behavior. > F. Something else. > > Which one, or a combination? I don't understand what you mean by "derived property" here. The existing text is non-normative and does not sufficiently explain how the values of the SVO/MVO map to the actual placement of glyphs in vertical text runs. The use of pseudo-code is part of the problem, the use of symbols with unclear definitions is another. I think the replacement text I proposed solves this and is clearer: For the 'mixed-right' and 'upright' property values, vertical orientation is defined in terms of the corresponding Unicode property value, MVO and SVO respectively. If the orientation value is "R" then the glyph is rotated right. If the orientation value is "U", "T", "Tu", or "Tr" then the glyph is displayed upright. The one exception is for scripts like Mongolian for which special handling is required for the stacked case due to the vertical-only nature of the underlying script. I think with the last sentence and a discussion of Mongolian/Phags-pa in UTR50 is sufficient for interoperability, I don't see the need for a verbose explanation of SVO handling for these scripts. John Daggett
Received on Friday, 29 June 2012 09:01:30 UTC