[css3-writing-modes] tatechuyoko examples with real vs. synthetic glyphs

To aid in the discussion of how to specify the normative behavior for
the 'text-combine-horizontal' property, I put together a page of
examples showing the appearance of tatechuyoku using width-specific
variant glyphs and synthetic glyphs created by simply scaling the 
underlying full-width or default digit glyphs.  The posting below
includes a set of renderings using Hiragino Mincho on OSX:

http://lists.w3.org/Archives/Public/www-archive/2013Jul/0011.html

Each date or address shows five renderings, using the codepoints and
settings described below:

1. full-width digits, half-width variant enabled for 2 digits, third-width variant enabled for 3 digits
2. full-width digits, scaled to half for 2 digits, scaled to third for 3 digits
3. default digits, no features or scaling
4. default digits, half-width variant enabled for 2 digits, third-width variant enabled for 3 digits
5. default digits, scaled to half for 2 digits, scaled to third for 3 digits

Cases (1) and (4) are the ideal.  They look identical because
regardless of whether full-width or normal ASCII digits are used, the
right width variant is used.  Case (2) shows how awful full-width digit
glyphs look when scaled.  Case (5) shows the result of scaling the
glyphs for ASCII digits.  In the two-digit case it doesn't look much
different from the variant glyph but you can see a distinct quality
difference for the three-digit case.  This will result in reduced
readability at normal text sizes.

The current ED allows user agents to render (1), (2), (4), or (5). 
After the changes that were resolved on yesterday's telecon, only (4)
and (5) will be possible.  The one remaining issue is that user agents
can still completely ignore the width variants, even if the font has
them, and simply always render (5).

I think it's much better and not difficult to require that user agents
render with the variant glyphs (4) if possible, and use scaling (5)
otherwise.  This is neither difficult to spec nor difficult to
implement and it in no way restricts the way this might be done in the
future.  Given that this means better quality across user agents, I
feel we should resolve on this improvement.

Regards,

John

Received on Thursday, 4 July 2013 07:59:19 UTC