Re: real vs. synthetic width glyphs



On 7/8/13 2:57 PM, "Florian Rivoal" <florian@rivoal.net> wrote:

>> 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.
>
>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).

I'm not sure whether or how we can clearly define what 'not too much
worse' 
means...

When giving implementors the ability to experiment may force authors to
do more work than necessary to achieve consistent results we are putting
implementors ahead of authors. (And, in this case, ahead of type designers
as well). 


>
>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
>obvious
>what the best thing is, and leaving that undefined is certainly fine with
> 
>me.
>
>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.

Right. To use small-caps as an analogy: if the font has the small caps
glyphs 
you need you're supposed to use them. But if they're not present there is
no 
strict definition of what fallback you should use. css3-fonts only says
UAs 
'should simulate a small-caps font, for example by…' scaling uppercase
glyphs.
This leaves the door open to UA innovation when the type designer didn't
do the 
job.

This is also true for other variant features, as well as for other font
properties 
like font-style and font-weight where UAs should only synthesize glyphs as
a fallback. 
I'm not sure what we gain by allowing implementations to violate this
expectation here. 

>
>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 22:48:42 UTC