Re: [css3-writing-modes] need use case for disabling full-width variants in tatechuyoko runs (was: [CSSWG] Minutes Telecon 2013-08-08)

Koji Ishii wrote:

>> I think this last point gets to the heart of this issue, what
>> possible real-world scenario requires this additional complexity? I
>> think we need at least to have a concrete example of an authoring
>> pattern combined with actual fonts that requires this. Without an
>> actual strong reason I think we should simply omit the "disable
>> full-width variants" requirement.
> 
> What I can't get well of this discussion is that, it looks to me
> that we all agree on the use case. It's already demonstrated at
> EXAMPLE 19 of the spec[1].
> 
> fantasai and I assumed that authors would want to use
> 'text-transform: full-width' or 'font-variant’ value of ‘full-width'
> to achieve the effect. A few weeks ago, you proposed that, authors
> may want to use full-width code points instead, so we added that
> complexity.

The use of 'text-transform: full-width' is not equivalent to
'font-variant: full-width' in actual usage.  Consider the real-world
example below.  Across Windows/OSX/iOS environments, there are only a
couple Mincho fonts available, the Japanese equivalent of a serif font:

  p {
    writing-mode: vertical-rl;
    font-family: Hiragino Mincho ProN, MS Mincho, serif;
    text-transform: full-width;
  }

  .date { /* dates with tatechuyoko (縦中横) */
    text-combine-horizontal: digits;
  }

With these settings, an author can use normal ASCII digits within
their dates.  Width variants will be used when digits are combined and
the glyph for the full-width *codepoint* will be used otherwise.  For
Hiragino Mincho this doesn't make a difference, the glyphs for the
ASCII digits don't differ from those of their full-width codepoint
equivalents.  Only the *width* is different, which doesn't affect
presentation within vertical text runs.  For MS Mincho however, the
glyph for the full-width codepoint is a different design than the
0.5em wide default ASCII digits.  MS Mincho doesn't have width
variants (see examples here [1]).

The style settings below may seem to be equivalent but they aren't:

  p {
    writing-mode: vertical-rl;
    font-family: Hiragino Mincho ProN, MS Mincho, serif;
    text-orientation: upright;
    font-variant: full-width;
  }

In this case, when digits are not combined within tatechuyoko runs,
full-width variants are requested for normal ASCII digits.  In the
case of Hiragino Mincho ProN, when digits are not combined the
full-width variant will be used.  But since this is just the same
glyph with a different width, the author will see no effect on the
content of vertical text runs.  In the MS Mincho case however, since
the font lacks support for the full-width variation feature, the
default 0.5em half-width glyph will be used rather than the more
desirable, full-width glyph design.  The result is that the use
of 'font-variant: full-width' has *no* effect on the appearance
of vertical text runs in this case!!

The other thing I should point out is that for most fonts that support
full-width variants, disabling full-width variations when other width
variants are enabled is basically a no-op, it has no effect on the
final result for most fonts.  This is because in OpenType, conflicting
font features are resolved by the order of features within the font.

For most Japanese fonts that support width variants, the font feature
settings below are equivalent:

  /* half-width variants will always "win" for most fonts */
  font-feature-settings: "fwid" on, "hwid" on;
  font-feature-settings: "fwid" off, "hwid" on;
  font-feature-settings: "hwid" on, "fwid" on;
  font-feature-settings: "hwid" on, "fwid" off;

When full-width variants are ordered before other width variants, the
latter width variants always effectively override full-width variants,
as defined by the OpenType spec.

> Now you're saying it's too complex. Why did we then added full-width
> code point complexity?
> 
> It looks to me that, all agree on the real-world scenario. It's just
> we don't agree on which method authors would use, neither of us can
> provide proof.

I'm saying that automatically disabling full-width variants in
tatechuyoko runs doesn't fit any real-world use and is unnecessary
because of the way most fonts prioritize width variant features.

I've used actual fonts and possible authoring styles to test my
assertions that the disabling of full-width variants is unnecessary.
If you don't feel this is the case I think you need to show some
real-world usage pattern where this automatic behavior is needed.

Cheers,

John Daggett

[1] http://lists.w3.org/Archives/Public/www-archive/2013Jul/0000.html

Received on Monday, 12 August 2013 00:54:38 UTC