Re: advanced font features in CSS

More discussion below.

On Mon, Jun 29, 2009 at 4:04 AM, John Daggett<jdaggett@mozilla.com> wrote:
>
>>> For example, OpenType allows distinct sets of glyphs with
>>> a common style to be specified independently but the 'styleset' value
>>> defined here is associated with a single numeric value, so only one of
>>> these stylesets could be applied at a time.
>>
>> Why on earth would you do that?
>
> Um, can you explain a little more?  Are stylesets commonly used as
> distinct sets that can be mixed?  That seems to be the theory, I wasn't
> sure whether fonts implemented this in practice.

Sorry, I should have been more clear.

In truth, the original intent of the feature did not include that.
However, the writeup allowed it, and type designers quickly made use
of it. For example, my own Hypatia Sans (registration incentive for
Creative Suite 3 applications) has ~14 stylistic sets, and they
generally do independent things (modulo those cases where one set is
simply a superset of of several others).

>>> Others, such as the CJK related glyphset and width properties listed
>>> below seem like interesting candidates for inclusion but I'm still
>>> unsure of the exact set of properties/values that are supported
>>> currently.
>>
>> What do you mean by "supported" in this context? By fonts, by the
>> spec, by applications?
>>
>>> Other properties still under investigation
>>>
>>>   font-variant-east-asian: normal | [<char-variant-value> | <char-width-value>]+ ;
>>>   <char-variant-value> :== hojo-kanji | jis04 | jis78 | jis83 | jis90 | nlckanji | simplified | traditional | traditional-names
>>>   <char-width-value>   :== full-width | half-width | third-width | quarter-width | proportional
>>
>> Under investigation by whom? What do you want to know?
>
> I'm wondering about the support for these variations in fonts and to
> what degree they are needed.  Are all these values still in common use
> or have some been obsoleted by later additions?  I just want to confirm
> that the answer is yes before adding them so that we don't end up with
> variations that exist in theory but aren't in use.

I believe that most of these properties are used by Adobe, Apple and
Microsoft in their Japanese fonts of recent years (Kozuka Gothic,
Mozuka Mincho, Haragino Mincho, Meiryo). I can do some quick checking.

> I'm also concerned that there's some crossover with support for Unicode
> variation sequences

There absolutely is. Tons of crossover. In fact, the very first
Unicode variation sequences to be registered were by Adobe, to
represent the same things also represented by the OpenType layout
features in question.

> and in some ways that might be a better way to
> support this (i.e. encourage the use of Unicode variation sequences,

One could. At this time, there are more fonts doing the OpenType
approach than the variation sequence approach. Perhaps this is simply
a side effect of the OT approach being older. I honestly don't know
whether one or the other approach will win out in the long run.

Unicode variation sequences can work in plain text and degrade just as
nicely as OT layout (as long as the app is savvy enough). However,
Unicode variation sequqnces require the user creating the content be
aware of some huge table as to what variant number equals which
variant form, for every glyph they care about, and that they know with
certainty which glyphs variants are applicable to. OpenType layout
suggests that the user just paints the relevant text with some
formatting, and any characters that are susceptible to the type of
variant in question "just work."

>From a UA POV, if they are doing the OpenType layout features for
other stuff, doing them here as well is a very low-cost addition.
Supporting character variants (which is done through a special cmap
mechanism in OpenType fonts) would be a bit more work.

If you want to do a more technology-neutral implementation in CSS,
then you probably ought to do both.

But unless you want to add some other value, I'm not sure you need to
even spell out a damn thing about variation sequences. Between Unicode
describing the plain text representation, and OpenType describing how
it's supported (in the 'cmap' table), all the info is there. Doing it
is simply part of keeping up with additions to the Unicode spec, and
needs to be done for any theoretical agent that claims to be fully
Unicode compliant (though I'm not sure there is such a thing).

> look up to see if a font supports a given variant and fallback if it
> doesn't).

If one falls back to the same font for the base character, that is the
same effect as the font not supporting the variant and the UA simply
ignoring that lack of support.

If one falls back to a different font, even when the font supports the
base character, that suggests we are assuming that getting the correct
variant is more important than maintaining the same font. I am not at
all sure that would be a reasonable assumption. Certainly that is not
the implementation path Adobe has done: they fall back to the base
character.

>>> Some feature selections only apply to a single font.  Swashes and
>>> styleset values are defined differently across fonts,
>>
>> Yes for stylistic sets, no for swashes.
>
> Interesting, I've heard others say just the opposite, namely that
> swashes are very contextual, one designs with a specific font in mind.
> When fallback occurs 'swash 5' will have a completely different meaning
> to another font.

Ah, that makes sense to me now. However, it assumes that as actually
implemented in fonts, there is more than one swash variant, which is
activated by manual user selection from the various swashes. Although
this is a perfectly legitimate use of the feature as described in the
spec, most font vendors are making it all work automatically (via
'swsh' and 'cswh' plus potentially interactions with 'calt', 'liga'
and 'dlig').

I think in practice you want to *at least* support global blind
application of "swash #1" and also support users choosing specific
swash #'s on specific glyphs.

>>>   normal: clears all features below, uses font defaults
>>>   common-ligs: liga (OT), ligatures = common (AAT)
>>>   additional-ligs: dlig (OT), AAT?
>>>   historical-ligs: hlig (OT), ligatures = rare (AAT)
>>>   no-xxx: disables features above
>>
>> Here you do have a problem in that the mapping between OT and AAT is
>> imperfect, and some bits of each do not clearly map to the other. In
>> essence you need to either pick one and squish the other into that
>> mold, or define unique properties where there isn't a clear mapping
>> (in the latter case, you'd give a separate feature for AAT "rare"
>> ligatures which would seem to be an amalgam of dlig and hlig).
>
> I realize this, I think the best way is to target OpenType features and
> try to do the best possible for AAT features.  Maybe both
> additional-ligs and historical-ligs should enable AAT rare ligatures?

Hmmm. Not a bad idea.

>>>   <caps-value> :== small-caps | petite-caps | titling-caps
>>>
>>> where these keywords imply the following underlying features
>>>
>>>   normal: clears all features below, uses font defaults
>>>   small-caps: smcp (OT), letter case = small caps (AAT)
>>>   petite-caps: pcap (OT), not in AAT
>>>   titling-caps: titl (OT), style options = titling caps (AAT)
>>>
>>> All capitalization values are mutually exclusive.
>>
>> So you don't want to provide access to the usual features to map from
>> caps to small caps (and petite caps)? The above features for smcp and
>> pcap only map from lowercase characters. Given the HTML/CSS desire for
>> separation of form and content, and the desire to keep the original
>> content intact, this seems like a mistake. Surely you don't want the
>> underlying text to have to read "unesco" rather than "UNESCO" just
>> because the designer wanted to format it in small caps?
>
> Wasn't sure about this.  CSS already has text-transform: lowercase, it
> seemed like you could define the combination of text-transform:
> lowercase and font-variant: small-caps to imply enabling those features
> if available, otherwise use character transform + small/petite caps.
> That way authors already doing this today would get the right thing.

That works, too. I'd be inclined to support both routes, but It's not
a big deal either way.

Regards,

T

Received on Monday, 29 June 2009 15:15:29 UTC