W3C home > Mailing lists > Public > www-style@w3.org > July 2013

Re: real vs. synthetic width glyphs

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 9 Jul 2013 18:33:06 -0700 (PDT)
To: www-style@w3.org
Message-ID: <485517303.441203.1373419986007.JavaMail.zimbra@mozilla.com>

Florian Rivoal wrote:

> In the example posted by John, I agree that MI is nicer in case (5)
> than (4), but MM is not. So this could indeed be a reason to let the
> UA be smart. But should that be by default, or opt in? Given that MI
> isn't the main use case, and that for digits (which are), (4) is
> always better than (5), I must admit that I do find the opt-in
> solution tempting. But at least now, I can see that there are
> situations where all variant glyphs are available but using them
> isn't the ideal.

I think looking at individual combinations of glyphs is the wrong way
to judge optimality here.  Tatechuyoko runs are used in body text, the
primary criteria really should be readability, not whether individual
combinations "look better".  That's what a type designer's job is, to
design the glyphs to be readable when used in combination with other
glyphs.

Using different scale factors based on the width of proportional
glyphs will *reduce* the readability, since it will effectively lead
to weight changes within text runs that will distract from the
content.  I think we should defer the problems of readability to type
designers, that's their natural role, rather than leave it up to the UA
to solve through synthesized magic.

I think having a strong required default with the possibility of
author opt-out is best.  If an author really wants to use scaled
proportional glyphs, then using an explicit override should work:

.tcy {
  font-feature-settings: "hwid" off, "twid" off;
}

This effectively disables the use of width variants and so the UA
will scale default glyphs.  I doubt any author will opt for this but 
it's an option.

Cheers,

John Daggett
Received on Wednesday, 10 July 2013 01:33:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 July 2013 01:33:33 UTC