Re: real vs. synthetic width glyphs



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

As I'm catching up with this thread I find John's appeal to consistency
quite convincing. I very much doubt a near future where Firefox uses the
proper width variant while IE or Chrome use a scaled glyph would be
perceived as some exciting future opportunity by the authors dealing with
the result. I really do not understand what is so valuable in keeping this
undefined that it's OK to force authors to add font-feature-settings
declaration to achieve what they want across UAs. Only people who want to
opt out of using the font's built-in variants should have to do extra work
in this case.

Last, this is also about platform consistency; existing CSS Fonts features
generally align with John's model e.g. implementations should not
synthesize 
italics if an italic face is available. Once the author chooses a font, we
should strive to respect both the author *and* type designer's intents by
default.

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