[MPEG-OTSPEC] Issues from CSS: Will they be covered by the text shaping WG?

[Peter Constable]

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of fantasai

>> 2. Italic / Oblique Default Angle

>The question is, given a font with a variable slant axis, if the author requests an "italic" or "oblique" font but does not specify a desired slant, how should the font designer communicate its preferred slant for such usage to the UA?

If it's a variable font with a slant axis, the fvar table has a default slnt value, and the post.italicAngle should give a corresponding value for the default. (The post.italicAngle could be varied using the MVAR table.)

Now, if the default slnt is upright, and the font supports oblique, I can see there'd be a question as to how a client could determine what slnt value to request to get something the designer would recommend for oblique. So, I gather that's the gap you're looking to fill.

The font could have an "Oblique" named instance, but that wouldn't be a reliable mechanism for that purpose. And of course the fvar would indicate max and min, slnt values, but those could be anything and not what the designer would recommend be picked in an automated way.

There is another mechanism that perhaps could be used: every variable font is required to have a STAT (style attributes) table, which provide some additional info regarding values on each of the variation axes. One thing that STAT can be used for is to provide info for traditional style-linking UI behaviours—i.e., what do you get when a use clicks the "B" icon, or the "I" icon. A font with a slnt axis would likely have data for the slnt axis "Normal" ("Upright", or whatever) value; that data could also indicate the "I" style linking value. So, if there were a way to determine which is that data in the STAT table, then we could recommend that fonts with slnt axes also provide that style-linking info to point to a preferred "Oblique" value. Of course, that would still leave a question of how you can determine the entry for "Normal" slant.

So, should this be in scope for a "shaping" working group? Well, that really depends on the scope. It's certainly in scope for the OpenType format, but I don't think of that as in scope for what I'd consider "shaping". It has more to do with font selection and the data needed for that than it does with shaping.


>> 5. Clarifications for Bopomofo

>... documentation to help implementers understand how to support Bopomofo tone mark positioning is what's needed (and in the spec particularly...

I don't think that belongs in the OpenType spec proper, just has the OT spec doesn't include specs with details for implementing shaping for any other script, beyond description of feature tags. But it certainly could be in scope for some different spec(s) on how shaping engines or fonts should be implemented to support particular scripts.


>Basically, from CSS's perspective, features can be
 >  * mandatory (never turned off because required for correct shaping)
 >  * optional, on by default
 >  * optional, off by default
>OpenType mentions on vs off by default, but is less clear about mandatory vs optional.

Yes, that is something that could be improved in the feature tag descriptions.



Peter