RE: real vs. synthetic width glyphs

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?

How should implementation do when the text is "#12", and Adobe standard glyph set doesn't provide twid for "#"? Use of "'" (apostrophes), "#", or "." (periods) are secondary-common, next to two-digits. I haven't determined the best algorithm in this case. Possible options from top of my head are: use twid for available glyphs and then scale, combine available twid with scaled "#", or not to use width-specific variants and scale whole text. Examining these results, determine the best one, and write it down into the spec looks too much to me.

I prefer to defer it to implementers for now. If we know no further invention will be done here in future and wants pixel/glyph-level consistency, we could add it in future levels.

/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Wednesday, July 03, 2013 1:30 PM
To: www-style@w3.org
Subject: Re: [css3-writing-modes] real vs. synthetic width glyphs


fantasai wrote:

> > Elika proposed something similar [1] but and Koji's response was 
> > "nah, undefined is better" [2].  However, I think if scaling to 1em 
> > is a requirement then how that occurs must to be defined explicitly. 
> > Leaving it undefined would force authors to work around naive 
> > implementations that simply scale whatever the content is, even if 
> > full-width codepoints are used.  I think the examples above make it 
> > plain that's not a good idea.
> 
> I think it would be *great* to put your algorithm here as an example 
> of good practice, and to point out the dangers of not converting 
> full-width codepoints to half-width variants.
> 
> However, I think I'm convinced by Koji and others that the spec's 
> normative requirements should leave the exact implementation of this 
> open, in case UAs are able to improve on it.

How is a *browser engineer* going to improve on the quality of a variant glyph specifically designed by a *type designer* for this case?!? This isn't "allowing improvement", it's permitting substandard baseline implementations, let's not kid ourselves here. In effect this is defining the baseline functionality to be a simple, crude scaling operation. The examples I put together clearly show the problem with this, the synthesized versions are very poor substitutes for real, designed variants [1].  This isn't about promoting better quality in the future, it's about permitting lower quality implementations.

Given that CSS3 Fonts spec and the use of vertical alternates in Writing Modes already requires a base level support of OpenType features, I see no reason to not make this a requirement rather than simply a best practice.  If you want to state this in abstract, non-OpenType terms, that would be fine:

  "If width-specific variant glyphs are available
   they must be used otherwise the user agent must
   render the content so that it fits within the line."

This will assure better consistency in the rendered results across user agents displaying web content.  If some vertical market publishing app only wants to implement this via scaling, that's their choice.  But there's no reason for us to specify such behavior in the spec.

Regards,

John

[1] http://lists.w3.org/Archives/Public/www-archive/2013Jul/0000.html

Received on Wednesday, 3 July 2013 05:26:48 UTC