Re: [css3-writing-modes] Examples of normal, unscaled glyphs work better than width-variant glyphs for text-combine-horizontal

Koji Ishii wrote:

> 1. One real example is on the spec[1]. This publication uses normal,
> unscaled glyphs for text-combine'd digits. By looking carefully at
> "10" and "27", you will find that they're slightly wider than other
> Kanji/Kana characters, which are 1em wide. You will also find that "2"
> is exactly the same glyph as its sideways rotated one.

Koji, I'm guessing this example is actually using half-width glyphs. 
The "slightly wider than other Kanji/Kana characters" is exactly how
this same example renders in Hiragino Mincho using half-width variants:

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

You really need to actually test with real fonts rather than guess at
how a print example was constructed.

> 2. Not a specific example but old revisions of the spec said that UA
> should scale only if it's wider than 1.1em tolerance. We removed it as
> per WG resolution, but the original motivation was that JLREQ, along
> with typographers and font designers preferred normal glyphs rather
> than width-variants if overflow is small enough to not worry about
> overlaps, similar to optical alignment in Latin typography.
> 
> 3. Rare case but a scan of a sci-fi novel of a crazy computer is
> here[2]. Engineers in the novel are discussing about an "if" statement
> of the computer program. It makes more sense to use normal
> proportional glyphs here since it's a regular word and it can fit
> within 1em.
> 
> Hope these examples make sense to agree that there are cases where the
> use of width-variant does not produce the optimal results.

Neither of these are examples where a *user agent* could make a better
choice, it's where an *author* would want to make a choice, based on
the specific snippet of text and the font used.

Using Hiragino Mincho, I went through and generated a set of examples
for two-letter combinations.  The main problem with scaling
proportional glyphs is that the scale factor will vary based on the
width, from no scale factor for combinations like "ii" measuring less
than 1em to combinations measuring almost 2em like "WW".  As the scale
factor increases, the effective weight of the face will be reduced and
the user will see lighter, less readable text.  For some letter
combinations, authors may prefer one over the other but that choice is
by no means universally so.

Two letter combinations, rendered with Hiragino Mincho ProN.  On the
left are the results using half-width glyphs, on the right scaled
versions of the default proportional glyphs. The scaling operation is
basically "if the width of the pair of glyphs is wider than 1em, scale
down to 1em".  The pairs are rendered in ascending order of default
glyph width for each pair:

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

Note how using proportional glyphs makes the text hard to read in
several cases, the "fi" looks like another letter, the "i" in "Ci" is
hard to separate from the "C", and it's hard to know whether the "I"
in "IQ" is an "I" or a "1".  At the bottom of the list combinations
like "mo" and "WW" are completely washed out in the scaled case. The
half-width variants aren't always the most aesthetically better but
they are consistently readable.  But the aesthetic judgement here is
one an author should make, not a user agent.

Using width variants is really the best choice for default behavior,
it assures consistent readability across user agents, independent of
the underlying text in a tatechuyoko run.  Authors who prefer scaled
results for a particular letter combination can simply disable width
variants but that's really something best left up to the author *not*
the user agent.

John Daggett

Received on Tuesday, 16 July 2013 05:22:16 UTC