RE: real vs. synthetic width glyphs

> From: Sylvain Galineau [mailto:galineau@adobe.com]
> >> 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'm sorry to say this but I still can't understand your opinion on mixed-case. Do you want to force UA to use 1/n glyphs if only some of them have the 1/n glyphs while others do not?

Here[1] is the example. "#" doesn't have qwid, while digits do, so the above example is a combination of "normal #" + "qwid 123", then scaled to fit into 1em. You can see "#" has heavier weight than "123", and "123" are compressed too much because they're applied qwid then compressed.

And this is not hypothetic. By shipping hwid/twid/qwid implementation for more than a year, we've got this feedback from real authors; "# + digits" are used as footnote marks in some good number of contents.

Sorry to repeat the question but can I ask your opinion what you want in this specific case? I know it's too specific question but my English prevents me understanding what you want, and it can clarify what you want.


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

You know WebKit and Blink has shipped hwid/twid/qwid for more than years, and IE11 has implemented it too, right? I can't see any chance of Mozilla to miss it given John and fantasai are there.

And you're worried about the possibility of IE and Chrome to intentionally degrade their already properly implemented functionality in future?

[1] http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0019/tcy-scale-test1.png

Received on Wednesday, 10 July 2013 13:52:52 UTC