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

On Mon, Jul 1, 2013 at 7:24 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:

> 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 agree (with Koji). We should not be prescribing specific use of OT
features. However, if sufficiently important, we can define behavior that
could be mapped to those features in an implementation specific way.


>
> 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
>
>