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 01:47:33 UTC