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

Koji Ishii wrote:

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

Eh, what?!?  You told me yourself when you, Elika and I sat down
and discussed this at the Mozilla Japan office last month that your
implementation was using the hwid/twid/qwid features and scaling the
result if necessary.  Using outline interpolation (Adobe MM, Apple
Variation Axes) is total overkill here, like swatting a fly with a
shotgun.  And it won't work, the glyphs for full-width digits will
still scale in a way that won't display very well.  See the examples
in my original post, you'll get similar results with an outline
interpolation approach.

Hiragino Mincho digits:
http://lists.w3.org/Archives/Public/www-archive/2013Jul/att-0000/widths-hiragino-mincho.png

Note how wide the spacing of full-width digits is.  If you scale the
outline down you'll still end up with something like the results
listed next to "full-width codepoints, scaled to third".

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

There's no "limitation" here, if future functionality becomes available
both specs and implementations can be updated to allow wider latitude.
The primary use case for these width features is in fact tatechuyoko,
so why, oh why, would you *not* use them if available? You seem to
want to *encourage* the use of hacky synthesized rendering as the
baseline for this feature and I think that's both unnecessary given
that font features are widely supported and detrimental to the web
platform.

Look at the examples in my original post [1], the difference between
real, designed glyphs and synthesized versions is night and day.  I
think the baseline functionality should be "use the real glyphs if
available, otherwise fake if necessary" rather than simply "fake if
necessary".  I don't think CSS should actively encourage bad
typography on the web.

I should also point out that implementating the Writing Modes spec
already requires the use of OpenType features to get proper vertical
alternates, so I don't see that requiring width variants is any
additional burden on implementations.

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

Full-width digits are used all over the place in horizontal Japanese
text on the web.  The nature of Japanese IME's makes this totally
natural, when entering numbers in a stream of Japanese text the IME
will always present both default ASCII digits *and* full-width digits
as an alternate.  Many Japanese address forms on the web *require* the
use of full-width digits, entering ASCII digits will result in an
error.  Displaying these addresses in vertical text runs will result
in exactly the use case you claim doesn't exist in practice.

So I fail to see how you can assert that they *won't* be used in
vertical text runs.  I think part of the problem is that you're
talking to a select audience of publishers rather than the more
general audience of web authors that will use this feature once the
functionality of this spec is more widely implemented.

Regards,

John

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

Received on Wednesday, 3 July 2013 02:27:25 UTC