RE: font features in CSS

Comments inline below

Steve Zilles

> -----Original Message-----
> From: Jonathan Kew [mailto:jonathan@jfkew.plus.com]
> Sent: Wednesday, October 28, 2009 10:05 PM
> To: Stephen Zilles
> Cc: Håkon Wium Lie; www-style; www-font
> Subject: Re: font features in CSS
> 
> On 28 Oct 2009, at 22:27, Stephen Zilles wrote:
> 
> > So, I do not propose, as the above prior proposals did, that we add
> > a bunch of properties. I do, however, propose that we add a registry
> > that gives long names (understandable and suggestive names) that map
> > to one or more 4 letter codes.
> 
> I'm not sure how you are intending this to be used? Do you mean a
> registry that authors would refer to, in order to know what 4-letter
> tags to include in their CSS? Or would the "long names" be used in the
> stylesheet itself, and the UA would then use the registry to map these
> to the 4-letter tags?

[SZ] I meant that CSS would use the long names and implementers would use the registry to find the related OT tag value.
> 
> One of the reasons to propose specific properties (font-variant-* or
> whatever) for "well-known" features is that it allows the CSS to be
> less closely tied to the underlying font technology. While the current
> focus is on OpenType, we should not tie CSS to that. Similar features
> can also be implemented in AAT, Graphite, or perhaps other
> technologies. If CSS defines a collection of typographic-feature
> properties, then authors can express their choices in a technology-
> independent way and UAs can realize these through whatever font
> technology(ies) they support.

[SZ] I would agree that having some features have explicit properties might be useful, but there are so many OT feature tags that doing them all is not practical. Furthermore, even with something like ligatures there are multiple features that control, in increasing specificity, which ligatures are to be used. Note that with long names, it is conceivably possible to map the long names to features represented in other font technologies provided that those features do the same thing as the OT features.
> 
> > So, one approach would be to make the "=number" part optional. If
> > omitted, the feature would simply be toggled. Why "toggled" you ask.
> > Because it makes sense for some of the features to be, by default,
> > enabled. And, it is also necessary to be able to turn off a feature.
> > If an author were in doubt about the state of a feature (whether
> > enabled or disabled), then the author could always use the "=number"
> > form of the setting to set it to an explicit state.
> 
> Toggling seems potentially very confusing to me... especially once you
> start to think about cascading. "FEAT=number", where it is always
> explicit whether the feature is being turned on or off, is much
> clearer. 

[SZ] Note, I did say that the "FEAT=number" format would behave as you describe. I was only talking about toggling in the case where the "=number" is omitted.

(Another variant is the form that I implemented some years
> ago for XeTeX: it uses +FEAT to turn on, -FEAT to turn off. But then
> to support features that require a numeric argument, it uses
> +FEAT=number, which I don't much like.)
[SZ] Nor do I.
> 
> > [SZ] I strongly dislike "magic" because it is hard to remember and
> > it is hard to interpret. I would therefore suggest as set of
> > keywords that could be added to the setting of the basic property
> > value. There are two sets of these keywords: the first set consists
> > of "block" and "word"; the second set consists of "all", "first" and
> > "last". (I do not believe that this is an exhaustive set of possible
> > keywords, only a set sufficient to describe the Mozilla behavior.)
> 
> Mozilla isn't doing "magic" here; the magic is in the font's
> contextual lookups, where it belongs. (See my earlier reply to Håkon.)

[SZ] OK, I accept that the intent of the "ss05" feature for this font is to only replace the last character in a word (and apparently not replace punctuation like "&"). Discovering this, however, requires looking into the font in great detail and seems to me to not be very user friendly unless all fonts behave the same way for feature "ss05". Whether the magic comes from the font or from the browser, it still appears to be magic to the user unless there is a good, simple explanation that he/she can find and use. In addition, when font substitution occurs, due to being offline, then the substitute font may have a completely different set of stylistic sets and behave completely differently. Having some explicit indication of which characters should be affected would help in this case, but perhaps not enough to matter.

Received on Thursday, 29 October 2009 17:37:51 UTC