RE: [css3-writing-modes] real vs. synthetic width glyphs

Your and fantasai's requests contain four changes to the current spec in combination if I understand correctly.

fantasai proposed two changes:
A. Require use of OpenType hwid/twid/qwid features in a specific way
B. Allow resulting glyph up to line-height (not 1em) and thus it may conflict with ruby/underlines

You proposed two changes:
C. Normalize full-width to half-width before apply
A'. Require use of OpenType hwid/twid/qwid features in another specific way
D. Limit possible set of values for 'digits' to 2, 3, or 4

Do I understand correctly?

A/A'. Require use of OpenType hwid/twid/qwid features in a specific way

I do not like CSS Writing Modes normatively require an OpenType feature. Kobo, for instance, uses iType technology.

I also don't like us to require a specific algorithm where interoperability won't matter much. Either algorithm doesn't differ much from the other. The resulting layouts are interoperable, just a few glyphs and spacing differ.

I can't find a good value of defining that level of details at least in this level of the spec.


B. Allow resulting glyph up to line-height (not 1em) and thus it may conflict with ruby/underlines

I do not like resulting glyph conflicting with ruby or underlines. I understand font designers and typographers oftentimes prefer conflicts over scaling, but it's under assumption that authors will fix it before it's delivered to readers. Since CSS may fallback fonts, we should avoid conflicts.


C. Normalize full-width to half-width before apply

John's guess for authors to use full-width may be logical, but in real world at least as of today, everyone uses ASCII, and I've never heard of such requests during my interviews with dozens of authors and publishers.

I'm ok with this if you strongly desire, but I guess the need is very small. We also need to define which conversion should happen and which should not--for instance, we do not want full-width Kana converted to half-width Kana, though the case is unlikely. It looks to me that it's a bit overkill.


D. Limit possible set of values for 'digits' to 2, 3, or 4

I'm good with this change.


/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Monday, July 1, 2013 5:07 PM
To: www-style list
Subject: [css3-writing-modes] real vs. synthetic width glyphs


The CSS3 Writing Modes spec defines the 'text-combine-horizontal'
property to implement short, one-glyph wide inline horizontal runs of
two or three characters, referred to as 縦中横 (tatechuyoko) in Japanese.
The common use cases for this are within dates (e.g. １２月１５日) or for
small numbers (e.g. １００).

http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal


For numerals, the common use case, authors can use either ASCII digits
(1,2,3...) or full-width digits (１、２、３...).  The default orientation
of the former is rotated, and upright for the latter, so I think a
common usage pattern will be the use of full-width digits.

For both codepoint sets, fonts may provide width-specific variants for
use with tatechuyoko which are selected by enabling the OpenType
features associated with these.  In fonts used commonly for
publishing, half-width and third-width digit variants are common,
quarter-width less so.  The combination of codepoint choice and
feature choice leads to a somewhat confusing array of choices for
rendering "simple" digits:

- default ASCII digits
- default full-width digits
- half-width variations of digits
- third-width variations of digits

Note that the default ASCII digits and the half-width variations are
*not* the same!!  Some fonts will have half-width and third-width
variations, others won't.  To implement tatechuyoko using the existing
spec, implementations can either (1) use the width variations and
scale or (2) just scale the default glyphs.

Here are some examples that show the difference between using actual
half-width and third-width variations vs. synthetic scaled versions:

Testcase:
http://people.mozilla.org/~jdaggett/tests/width-testing.html


Hiragino Mincho 
(Apple/DaiNippon, default Japanese serif on OSX/iOS)
http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-hiragino-mincho.png


Kozuka Mincho
(Adobe)
http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-kozuka-mincho.png


MS Mincho and MS PMincho
(Microsoft, default Japanese serif on Windows)
http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-msmincho.png

http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-mspmincho.png


In all of these cases, the "full-width codepoints, scaled to third"
looks particularly bad, at normal text sizes on Windows this will be
basically unreadable, particularly with DirectWrite rendering:

IE10, MS Mincho third-width renderings:
http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-ie10-msmincho-twid.png


I think if the spec is going to require "compression" of a tatechuyoko
run to fit the run into 1em, then it should be defined clearly and not
left undefined.  Specifically, I don't think synthesizing tatechuyoko
from full-width glyphs should be allowed.  Allowing naive user agents
to render this way will force authors to target the "least common
denominator" rendering by avoiding full-width digits and I don't think
that's a great idea.

I would propose that the process of laying out tatechuyoko runs be:

1. Convert full-width codepoints to their default equivalents (i.e.
   full-width digits would switch to their ASCII digit equivalents)
2. Based on the length, apply the appropriate OpenType feature
   (i.e. half/third/quarter width)
3. Scale the result to 1em if necessary
4. Treat the resulting composition of glyphs as a single glyph that
   matches the metrics of typical ideographic glyphs for the font used
   (i.e. does *not* affect the size of the inline box).  The resulting
   composition of glyphs is defined to have no available substitions
   (i.e. none of the font-variant/font-feature-settings affect the
   rendering of the composition).

Elika proposed something similar [1] but and Koji's response was "nah,
undefined is better" [2].  However, I think if scaling to 1em is a
requirement then how that occurs must to be defined explicitly. 
Leaving it undefined would force authors to work around naive
implementations that simply scale whatever the content is, even if
full-width codepoints are used.  I think the examples above make it
plain that's not a good idea.

One additional note, I think the possible set of values for use with
'digits' should be limited to 2, 3, 4.  Anything else is nonsensical,
theoretically possible but illegible in practice.

Regards,

John Daggett

Received on Monday, 1 July 2013 13:25:23 UTC