RE: [css3-writing-modes] real vs. synthetic width glyphs

> iType is simply another OpenType/TrueType rendering engine.
 
iType can also support variable width, similar to Adobe Multiple Master. In that environment, require to use hwid/twid/qwid might not make sense.

But it's just an example. My point is, we should not limit ourselves to what OpenType can do in 2013, unless it's absolutely necessary for interoperability or whatever other critical reasons, and I do not find such a critical reason here. I'm fine to make an informative note to implementers recommending use of hwid/twid/qwid, but normatively requiring it will limit our extensibility in future. This is the first version we introduce vertical flow, I think extensibility is more important than subtle glyph quality.

> If an author wants to have upright digits, one usage pattern will be
> to use the full-width digit codepoints which are upright by default.
> My only desire here is to assure that no user agent ever synthesizes
> tatechuyoko runs using full-width glyphs, the examples in my original
> post clearly show that this is a poor choice.

I'm not opposed to it, but given no authors seem to be requesting it, it looks to me that it's overkill. You're right that it's logically one possible usage pattern, but if no one really do it, the feature is not necessary, right?

I'm glad that we're in consensus for not doing B and doing D.

/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Tuesday, July 2, 2013 10:47 AM
To: www-style list
Subject: Re: [css3-writing-modes] real vs. synthetic width glyphs


Koji Ishii wrote:

> A/A'. Require use of OpenType hwid/twid/qwid features in a specific 
> way
> 
> I do not like CSS Writing Modes normatively require an OpenType 
> feature. Kobo, for instance, uses iType technology.

Koji, this is a nonsequitor, iType is simply another OpenType/TrueType rendering engine.  Just like other OpenType engines, it appears to support substitution features. Look carefully at the iType documentation under "Specifications" [1]:

"Compatible Formats: TrueType and OpenType (TrueType + OpenType layout extensions)"

OpenType layout extensions == font feature support == width substitutions supported.

I think if you want to insist that scaling is done automatically for tatechuyoko, user agents must use the features if available.  Like real vs. synthetic italics, the difference is night and day in terms of quality.  The CSS3 Fonts spec requires OpenType support and it's widely available and implemented in user agents, via the 'font-feature-settings' property.

There's no good reason in 2013 not to require that *if* a font supports width variants that they be used. Naturally, if an implementation only uses fonts that lack these features there's no reason to support this but I doubt there will be many implementations like this in practice.  If a given implementation wants to leave out features, so be it, but there's no reason to set the bar so low given that support for CSS3 Fonts will require this support.

>From Elika's proposal:

> B. Allow resulting glyph up to line-height (not 1em) and thus it may
>    conflict with ruby/underlines

I'm not proposing this.  I think the user agent should determine the scale factor based on the font used and I'm perfectly happy to leave the exact algorithm undefined here since I think the variations across user agents will be very small.  If edge cases crop up then we can tweak the details at the next level.

I do think that it's important that the synthesized "glyph" be treated as any other glyph in the font, that it not change the dimensions of the inline box, thus it should not affect ruby, decorations etc.  The value of 'line-height' doesn't make sense to me.

> C. Normalize full-width to half-width before apply
> 
> John's guess for authors to use full-width may be logical, but in real 
> world at least as of today, everyone uses ASCII, and I've never heard 
> of such requests during my interviews with dozens of authors and 
> publishers.
> 
> I'm ok with this if you strongly desire, but I guess the need is very 
> small. We also need to define which conversion should happen and which 
> should not--for instance, we do not want full-width Kana converted to 
> half-width Kana, though the case is unlikely. It looks to me that it's 
> a bit overkill.

I think you're forgetting that the ASCII digit codepoints are rotated by default.  If an author wants to have upright digits, one usage pattern will be to use the full-width digit codepoints which are upright by default.  My only desire here is to assure that no user agent ever synthesizes tatechuyoko runs using full-width glyphs, the examples in my original post clearly show that this is a poor choice.

Worrying about kana is overkill since kana are not included in tatechuyoko runs.  Let's solve real problems, not non-existent ones.

> D. Limit possible set of values for 'digits' to 2, 3, or 4
> 
> I'm good with this change.

Great!

[1] Monotype iType description
http://www.monotypeimaging.com/images/ProductsServices/iType-lr.pdf

Received on Tuesday, 2 July 2013 12:58:06 UTC