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

My point is not about how easy/hard it is to implement, but since you seem to insist on it and since you seem to misunderstand me.

I know how harbuzz works. I understand what you described--multiple levels of mapping glyph ID in OpenType when more than one feature is activated.

When I said it's technically doable, I meant one could add an API to know if a code point's mapping chain contains 'vert' or not. I hope you agree that it's at least doable.

Your point as I understand is that, while it is technically doable, doing it is not worth to what you get. I understand that, and that's why we have the tailoring value definition in our spec. We are in consensus up to this point.

My point is that, if an implementer chose to do so for whatever reasons, either by himself or because such feature is already provided by underlying APIs, it makes no sense to put such implementation non-conformant to CSS, or force him to implement workaround to disable underlying implementations.

If underlying APIs provide, it makes no sense to discuss if the cost is worth the value, because not following UTR#50 costs more. Or if you're API developer and a browser developer asked you to add a flag to disable UTR#50 compliant-behavior, it costs more.

I accepted your proposal, understanding it is valuable to you and to other implementers. That is fine.

I do not see any values to prohibit Unicode-compliant implementations and ignore people who wants it, especially when some people specifically asked for it, just because other people does not think the work isn't worth to do. Whether it's worth or not varies by people and situations around him/her.

Do we understand how our discussion points are different?

/koji


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


James Clark wrote:

> So I would suggest that the spec should say that a UA must determine 
> whether an OpenType font provides an appropriate rotated glyph for a 
> Tr character by testing whether applying the 'locl' and 'vert' GSUB 
> features together to a glyph string consisting of the single glyph id 
> to which the character is mapped results in a change to the glyph 
> string.  This would ensure all OpenType-based implementatons behave 
> consistently with each other and with UTR#50. I can't see this having 
> a performance impact: there are relatively few Tr characters and you 
> can do this test up-front, once per font.

That's a simplification of OpenType layout.  Would that work most of the time for existing fonts? Yes. Would it be correct in all situations? No.  OpenType defines a set of default features and authors can apply extra features via properties like 'font-variant'
and 'font-feature-settings'.  In the general, non-script specific case, substitution features are applied in the order specified in the font, followed by positioning features in a similar manner.

Simple case:

            cmap             vert
  codepoint ====> glyph id A ====> glyph id B

When a feature isn't supported no change occurs to the glyph id, so if a font doesn't have a 'vert' substitution defined for A, you'll see A in the output instead of B.  So in this case you're running layout twice, once to determine the default glyph (A) and then to see if there's a substitution to (B).

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.

Japanese fonts today generally don't use features at this complexity level but you're starting to see more complexity in fonts such as Kazuraki from Adobe.  Which is why for future use I think it's important for layout engines not to encumber text shaping with fallback rules like the optional one described in the Writing Modes spec.

Looping back to the question of how 'Tr' codepoints should be handled, I think it's important to point out that there are 47 of these codepoints in all of Unicode and the Japanese fonts I tested supply vertical alternates for almost all of the characters supported within the font.  The missing ones I found were:

Kozuka Mincho Pr6N
3030 cid12218 vert: [] WAVY DASH
ff1b cid00640 vert: [] FULLWIDTH SEMICOLON

MS Mincho
ff1b uniFF1B vert: [] FULLWIDTH SEMICOLON

So that's what all this complexity boils down to -- fallback for these two codepoints.  This doesn't seem like a worthwhile tradeoff, especially given that the lack of vertical alternates in a font like Kozuka Mincho, which includes over 20,000 glyphs, suggests that the rotated form of these characters is not actually used a whole lot in practice.

Regards,

John Daggett

Received on Thursday, 26 September 2013 15:53:08 UTC