Re: real vs. synthetic width glyphs



On 7/9/13 8:13 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:

>> From: Sylvain Galineau [mailto:galineau@adobe.com]
>>
>> Like John, I am saying the UA should be required to use half-widths (or
>>1/n
>> widths) glyphs if they exist. Just like UAs must use small-caps glyphs
>>if they exist, use a
>> bold face if it's available etc. But when the fonts does not provide
>>1/n glyphs then, as in
>> the other cases above, the UA should synthesize them.
>> 
>> And for those cases where using existing 1/n glyphs is not optimal then
>>yes, it is OK to
>> provide a way to override the default.
>
>If 1/n width glyphs exist, and if using existing 1/n glyphs is not
>optimal, are you OK to provide a way to override the default or not?

By 'if using 1/n glyphs is not optimal' do you mean 'if *the author* does
not want to use the 1/n glyphs provided by the font'? If so then yes, it's
absolutely fine for them to be able to override the default behavior. It's
also fine for UAs to do something interesting when no such glyphs are
present in the specified font. I do not think any of this is really the
issue though.

The argument is about *requiring* interoperable behavior when the font
does provides 1/n glyphs. My understanding of the resolution is that it
does not actually do so.

>
>I hope us to clarify our goal.
>
>If we want to avoid poor implementation, the current resolution should do.
>
>If we want to prevent innovations, we need to prohibit someone to come up
>with better algorithms.
>
>I understand we want the former, and not the latter.

I do not think John's argument is really about poor implementations or
'preventing innovation'. I think the simplest way to summarize his
position may be: 'UAs should only synthesize glyphs as a fall-back, never
as a default'. Which also happens to be true in CSS thus far.

While - thankfully - the spec does not require UAs to synthesize glyphs by
default, it does allow them to do just that. Not only is this inconsistent
with other CSS features but it also means a future release of Firefox
could always use 1/n glyphs when present while other UAs like IE or Chrome
would always ignore them in favor of their own scaling magic. In some
cases Firefox may get nicer-looking but awkwardly spaced glyphs while
IE/Chrome may get better spacing in all cases but with poorer glyph
quality overall. Yet everyone is conformant! From the standpoint of web
authors such an outcome seems designed to make everybody equally unhappy
for quite some time.

I'll admit I can be slow but I'm having an awfully hard time understanding
the rationale for allowing cross-browser authoring pain when the type
designer already did all the work to address authors' needs in the
majority of use-cases.
 


>
>/koji
>

Received on Tuesday, 9 July 2013 18:09:53 UTC