Re: real vs. synthetic width glyphs

> On 7/2/13 11:30 PM, "John Daggett" <> wrote:
>> 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.

During the telconf, it was said that keeping our options open was useful
to enable implementers to do better than what we would other wise specify,
at the expense of letting them do somewhat worse as well (but not too much,
since we've banned the worse approach).

That sounded reasonable to me, but thinking more about it, I do not see
what better approach there could be when all the variant glyphs exist in
the font.

When only some of the glyphs are available, it is indeed not totally  
what the best thing is, and leaving that undefined is certainly fine with  

But when all the glyphs are available, leaving some wiggle room to the
implementation seems counter productive if the only way they can deviate
 from our preferred behavior is by being worse.

Or am I missing something? Is there indeed something better to be done than
using the variant glyphs when they are all available? What are we leaving
the door open to?

  - Florian

Received on Monday, 8 July 2013 21:57:29 UTC