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, 2 Jul 2013 23:30:26 -0700 (PDT)
To: www-style@w3.org
Message-ID: <1577438240.984771.1372833026443.JavaMail.zimbra@mozilla.com>

Koji Ishii wrote:

> It looks like we're getting better mutual understanding. You want
> pixel/glyph-level consistency by sacrificing future opportunities,
> while I think extensibility and freedom to invent better
> implementation is more important as long as layout consistency is
> promised, and I'm ok to sacrifice pixel/glyph-level consistency for
> it. Am I describing our opinions accurately?

No, I want to assure consistent, high-quality results by using existing
solutions.  Type designers already include glyphs that are appropriate
for tatechuyoko display, using those glyphs should be the standard. 
If you want wiggle room for user agents dealing with obscure edge
cases that rarely occur in practice (e.g. #12), fine, add wiggle room
for user agents to do what they see fit in those cases.  But there's
no reason to not do the right thing in the most common cases.  This
isn't hard.

Leaving this feature completely undefined permits the use of *any*
algorithm, good or bad.  Simply scaling and not using the proper
variant glyphs clearly results in poor quality rendering in some
cases.  By requiring the use of the width variants you're not
"sacrificing future opportunities", you're guaranteeing a good minimum
level of quality.

We should rely on type designers to provide glyphs appropriate for use
in tatechuyoko rather than rely on implementors to synthesize
something using some form of magic.

> I prefer to defer it to implementers for now. If we know no further
> invention will be done here in future and wants pixel/glyph-level
> consistency, we could add it in future levels.

There's no need for "invention" if a type designer has already solved
the problem!!!  We're not putting a man on the moon here...

John
Received on Wednesday, 3 July 2013 06:30:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 July 2013 06:30:54 UTC