Re: [css3-fonts] font-specific feature handling

Dear list members,

advanced typographic features in fonts can be generally classified into
three categories:

* "automatic": features required for orthographically correct default
language rendering, with a clearly defined purpose

* "optional font-unspecific": features that are not required for the
default language rendering, but which, when applied, perform a change in
the semantics or the formatting of the text according to general
conventions agreed among a larger group of users

* "optional font-specific": features that, when applied, perform a
change in the semantics or the formatting of the text according to
specific conventions defined by the developer of the font

All three kinds of features have its important use. One should remember
that none of these three groups of features is completely
font-unspecific. Various fonts may or may not include particular
features, and each of the features can be implemented in a variety of
ways. The degree of variety in the recommendations of how particular
features should be implemented does vary: typically, the recommended
implementation of the automatic features is defined in a rather strict
way while the recommended implementation of the optional font-specific
features is quite liberal.

The automatic features generally need no user control. They are
automatically applied by the layout engine in the process of text
rendering. Without them being applied, the resulting text is
orthographically incorrect or even unreadable. Each writing system has
its own rules on how these features are applied, and the layout engine
"knows" which features to apply, and how. In isolated cases, authors may
want to override them using the font-feature-settings property. This is
sometimes important, for example when authors write about linguistic
issues and would like to present text that is not rendered according to
the orthographic rules of a particular language, but is somehow
"incorrect", or is rendered according to some language-neutral rules or
rules of some minority language or spelling convention that has not been
standardized.

As I mentioned above, the optional font-unspecific features are not
entirely font-unspecific. They may differ in implementation, but there
is a general consensus on what kind of functionality a feature should
perform. For example, the OpenType Layout "smcp" feature should replace
lowercase glyphs with their smallcap equivalents, and the "c2sc" feature
should replace uppercase glyphs with their smallcap equivalents. Yet the
font developer still has freedom: for example, the font developer may
choose to also replace lining figures or some punctuation characters
(such as parantheses, dashes, the ampersand, quotation marks) with
variants that are designed in a way that is more suitable to be used
with smallcaps than the default forms.

Finally, there is a set of features such as stylistic sets or stylistic
alternates (OpenType "ss01"-"ss20" and "salt") which are intended to
provide the authors with the ability to apply specific semantic or
formatting changes to the text in a manner that is defined by the vendor
of the particular font. This is an important mechanism, which allows
font developers and web authors to bypass a centralized standardization
process. Some minority communities may never get their writing
conventions standardized, and some formatting variations only make sense
in a context of a specific font, or specific typographic convention.

Now comes my principal point: when an author decides to apply
font-specific features, he or she needs to be familiar with the
functionality of the font. This also means that the process of selecting
fallback scenarios needs to be a conscious decision of the author. It is
the web author's responsibility to choose fallback fonts that do not
perform formatting or semantic changes that are _unwanted_ by her or him.

In other words, when the author decides to apply a font-specific feature
through the CSS "stylistic" or "styleset" property, it should be the
author's responsibility to make sure that the fallback scenario does not
produce unwanted results. The author should choose such fallback fonts
that implement a similar functionality, or the author should choose such
fallback font that achieve "neutral" results.

However, I must agree with Jonathan that while my classification (above)
is neat, it is not one that can be drawn using hard lines. Some features
can be considered automatic or font-unspecific in different fonts, and
some features can be considered font-unspecific or font-specific in others.

Therefore: there is one scenario that might be an attempt to "eat the
cake and keep it" at the same time:

I would like to suggest that the CSS3 Fonts specification states that
the CSS font-feature-settings property be applied ONLY TO THE FIRST font
in the font stack. Since we agree that this is a "low-level" access
mechanism, we should also agree that the "low-level" is a highly
font-specific thing.

Therefore, I think that all CSS properties that all font rendering
properties in general should be applied to the main font as well as the
fallbacks, while the font-feature-settings property should not be
applied to the fallback fonts, as an exception.

This way, we have a simple yet effective mechanism to make sure that the
author has full control.

For example, if the author specifies font-variant: styleset(1,3), then
the OpenType Layout features "ss01" and "ss03" will be applied to the
main font as well as the fallback fonts, but if the author specifies
font-feature-settings: "ss01=1,ss03=1", then the OpenType Layout
features "ss01" and "ss03" will only be applied to the main font in the
stack.

To make this behavior more clear for authors, we could rename the CSS
property "font-feature-settings" to "font-specific-feature-settings".

How does that sound?

Regards,
Adam

Received on Monday, 22 March 2010 04:31:48 UTC