font features in CSS

[Håkon Wium Lie]

Prince 7.0 has been released with experimental support for OpenType
font "features". This means that glyph alternates present in the font
can be selected by way of CSS. Here's a sample document that uses
alternates found in Adobe's "Arno Pro" font:

  http://www.princexml.com/howcome/2009/magic/prince7.pdf
  http://www.princexml.com/howcome/2009/magic/prince7.html

The preliminary syntax for selecting various features is:

  font-variant: prince-opentype(<feature name>);

Mozilla is also working on supporting font features:

  http://hacks.mozilla.org/2009/10/font-control-for-designers/

Their preliminary syntax is:

  -moz-font-feature-opentype: "<feature-name>=<value>";

(Comma-separted lists are supported in both implementations.)

So, it seems font "features" could be a useful CSS feature. However,
some issues have come up:

  - the current implementations only support arbirary features. The
    names of these features are buried deep down within the fonts and
    are hard to find. Another approach is to standardize a set of
    common features. There have been several such proposals in the
    past:

      http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html
      http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html

    I personally think standardized names will be better, but it may
    still be hard to avoid cryptic names like "alt" and "salt".


  - Are features binary or do they need integer values? It seems that
    Prince has implemented features as binary switches, e.g.:

      font-variant: prince-opentype(salt2);

    while Mozilla uses integer values:

      -moz-font-feature-opentype: "salt=2";

    Personally, I hope to avoid numbers altogeter; they seem even more
    arbitrary than the alt/salt/ss names we're currently seeing.


  - Here's a reformulated version of Mozilla's demo document that
    contains both the Prince and Mozilla syntax, along with Prince's
    rendering:

      http://www.princexml.com/howcome/2009/megalopolis/sample.html
      http://www.princexml.com/howcome/2009/megalopolis/sample.pdf
      http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.png

    The page has been carefully designed so that all lines should have
    the same length. However, in Prince's renering, lines stick out.
    This is, I believe, due to Prince applying the named feature
    (ss05) in the case of the "Beua.." line) to all characters in the
    element, while Mozilla only applys it to the last character of a
    word. Mozilla's solution is convenient; it avoids having <span>
    elements around the last charater in order to give it a special
    feature. However, how do one decide that a certain feature should
    only be applied to the last characters? Does the feature itself
    indicate this in any way?

  - personal peeve: I don't like the term "font feature". The term
    "feature" seems much to generic to be used for a very specific
    feature (ouch): alternate glyphs.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@...                  http://people.opera.com/howcome

[Thomas Phinney-3]

On Mon, Oct 26, 2009 at 7:46 AM, Håkon Wium Lie <howcome@...> wrote:

>  - Are features binary or do they need integer values? It seems that
>    Prince has implemented features as binary switches, e.g.:
>
>      font-variant: prince-opentype(salt2);
>
>    while Mozilla uses integer values:
>
>      -moz-font-feature-opentype: "salt=2";
>
>    Personally, I hope to avoid numbers altogeter; they seem even more
>    arbitrary than the alt/salt/ss names we're currently seeing.

There are several different cases to consider regarding substitution
(GSUB) layout features:

A) Some take a "choose one of many" argument to determine the output
glyph. Stylistic alternates ('salt') are one of these, where there may
be several possible results and an argument must be given for which
one is desired. Ornaments ('ornm') is another.

B) GSUB features should be assumed to be potentially
cumulative/interactive with most other features. Naming a few of the
more common ones: stylistic sets (even with each other), superscript,
ligatures. So for example in my typeface Hypatia Sans, there is a
multi-way interaction between several of the different stylistic sets
and superscript, in which toggling any one of them changes the output
glyphs. Or similarly in Poetica, there's a nice interaction between
ligatures and swash variants....

C) Cases "A" and "B" above can theoretically interact. Nothing
stopping somebody from building a font in which "choose stylistic
alternate #2" interacts with "superscript" for example, and that might
seem pretty reasonable.

D) Some few GSUB features could reasonably be treated as mutually
exclusive, though one could also rely on the author not specifying
both, and not worry about what happens when both are assigned. For
example, proportional numbers and tabular numbers are mutually
exclusive, as are superscript and subscript.

>  - personal peeve: I don't like the term "font feature". The term
>    "feature" seems much to generic to be used for a very specific
>    feature (ouch): alternate glyphs.

In some folks' usage, the full term is "font layout feature." In any
case, it certainly includes a host of glyph positioning (GPOS)
features, such as kerning, and not only alternate glyphs.

Cheers,

T

[Robert O'Callahan-3]

On Tue, Oct 27, 2009 at 3:46 AM, Håkon Wium Lie <howcome@...> wrote:

Mozilla is also working on supporting font features:

 http://hacks.mozilla.org/2009/10/font-control-for-designers/

Their preliminary syntax is:

 -moz-font-feature-opentype: "<feature-name>=<value>";

(Comma-separted lists are supported in both implementations.)

So, it seems font "features" could be a useful CSS feature.

I think you know this, but just to be clear, John and Jonathan aren't proposing that authors normally work with Opentype feature names directly this way. Their actual proposal extends font-variant with "higher level" syntax, here:
http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html

-moz-font-feature-opentype is just simple experimental syntax that lets us work on implementation issues. We might want to expose something like it as an "advanced" feature for authors when the "higher level" syntax doesn't provide enough control.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Jonathan Kew-2]

Very cool, Håkon!

On 26 Oct 2009, at 08:46, Håkon Wium Lie wrote:

>  - Are features binary or do they need integer values? It seems that
>    Prince has implemented features as binary switches, e.g.:
>
>      font-variant: prince-opentype(salt2);
>
>    while Mozilla uses integer values:
>
>      -moz-font-feature-opentype: "salt=2";
>
>    Personally, I hope to avoid numbers altogeter; they seem even more
>    arbitrary than the alt/salt/ss names we're currently seeing.

Most features are typically implemented as simple booleans (for which  
we're using 0 and 1 to mean "off" and "on"), but I don't think you can  
avoid specifying numbers for "one-of-many" substitution features.

>  - Here's a reformulated version of Mozilla's demo document that
>    contains both the Prince and Mozilla syntax, along with Prince's
>    rendering:
>
>      http://www.princexml.com/howcome/2009/megalopolis/sample.html
>      http://www.princexml.com/howcome/2009/megalopolis/sample.pdf
>      http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.png
>
>    The page has been carefully designed so that all lines should have
>    the same length. However, in Prince's renering, lines stick out.
>    This is, I believe, due to Prince applying the named feature
>    (ss05) in the case of the "Beua.." line) to all characters in the
>    element, while Mozilla only applys it to the last character of a
>    word. Mozilla's solution is convenient; it avoids having <span>
>    elements around the last charater in order to give it a special
>    feature. However, how do one decide that a certain feature should
>    only be applied to the last characters? Does the feature itself
>    indicate this in any way?

I think you'll find that the 'ss05' feature uses a chaining contextual  
lookup to achieve this; perhaps whatever OpenType layout code Prince  
is using doesn't handle that?

JK

[Michael Day]

Hi Jonathan,

> I think you'll find that the 'ss05' feature uses a chaining contextual
> lookup to achieve this; perhaps whatever OpenType layout code Prince is
> using doesn't handle that?

Thanks for the tip!

We've implemented chaining contextual lookups in order to handle some
Indic fonts if I recall correctly, but it's a complex feature and it's
likely there are some remaining bugs that need squashing.

Best regards,

Michael

--
Print XML with Prince!
http://www.princexml.com

[Stephen Zilles]

See comments inline below.

Steve Zilles

> -----Original Message-----
> From: www-font-request@... [mailto:www-font-request@...] On Behalf Of
> Håkon Wium Lie
> Sent: Monday, October 26, 2009 7:46 AM
> To: www-style; www-font
> Subject: font features in CSS
>
> Prince 7.0 has been released with experimental support for OpenType
> font "features". This means that glyph alternates present in the font
> can be selected by way of CSS. Here's a sample document that uses
> alternates found in Adobe's "Arno Pro" font:
>
>   http://www.princexml.com/howcome/2009/magic/prince7.pdf
>   http://www.princexml.com/howcome/2009/magic/prince7.html
>
> The preliminary syntax for selecting various features is:
>
>   font-variant: prince-opentype(<feature name>);
>
> Mozilla is also working on supporting font features:
>
>   http://hacks.mozilla.org/2009/10/font-control-for-designers/
>
> Their preliminary syntax is:
>
>   -moz-font-feature-opentype: "<feature-name>=<value>";
>
> (Comma-separted lists are supported in both implementations.)
>
> So, it seems font "features" could be a useful CSS feature. However,
> some issues have come up:
>
>   - the current implementations only support arbitrary features. The
>     names of these features are buried deep down within the fonts and
>     are hard to find. Another approach is to standardize a set of
>     common features. There have been several such proposals in the
>     past:
>
>       http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html
>       http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
>
>     I personally think standardized names will be better, but it may
>     still be hard to avoid cryptic names like "alt" and "salt".

[SZ] My understanding from Adobe font guys is that the 4 letter feature names were never intended for human use. They are indeed cryptic. Adobe products that support those features only offer long names which map to the 4 letter codes, sometimes singly and other times to a combination of 4 letter codes when that makes more sense. For example, the long name, "All Small Caps" maps to the two features, "smcp" which converts lower case letters to small caps and "c2sc" which converts capital letters to small caps. (One might figure out that "smcp" stands for small caps, but I doubt that many will decipher "c2sc".)

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. For example, the OpenType Spec
  http://www.microsoft.com/typography/otspec/featurelist.htm
has a set of "friendly names" that might be used. Adobe InDesign also has a set of "user oriented" names. This would likely make the features more usable.

>
>
>   - Are features binary or do they need integer values? It seems that
>     Prince has implemented features as binary switches, e.g.:
>
>       font-variant: prince-opentype(salt2);
>
>     while Mozilla uses integer values:
>
>       -moz-font-feature-opentype: "salt=2";
>
>     Personally, I hope to avoid numbers altogeter; they seem even more
>     arbitrary than the alt/salt/ss names we're currently seeing.

[SZ] I would agree that numeric values are, in most cases, not necessary, but there are cases, such as "alternate glyphs" (a.k.a Stylistic Alternates) where more than one alternate may exist. For example, Adobe Poetica has multiple alternates for the ampersand "&" glyph. In this case, a numeric argument makes sense.

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.

>
>
>   - Here's a reformulated version of Mozilla's demo document that
>     contains both the Prince and Mozilla syntax, along with Prince's
>     rendering:
>
>       http://www.princexml.com/howcome/2009/megalopolis/sample.html
>       http://www.princexml.com/howcome/2009/megalopolis/sample.pdf
>       http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.png
>
>     The page has been carefully designed so that all lines should have
>     the same length. However, in Prince's renering, lines stick out.
>     This is, I believe, due to Prince applying the named feature
>     (ss05) in the case of the "Beua.." line) to all characters in the
>     element, while Mozilla only applys it to the last character of a
>     word. Mozilla's solution is convenient; it avoids having <span>
>     elements around the last charater in order to give it a special
>     feature. However, how do one decide that a certain feature should
>     only be applied to the last characters? Does the feature itself
>     indicate this in any way?

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

The meaning of the key words is that the enabled feature applies to either the first character, the last character or all the characters in a given block or all the words in a block. We can see from the MEgalopolis.png and the associated .html file that Mozilla is applying the "ss05" feature to the "last" of every "word" (see "Beau Grand & Fort") This might have been written (in the stylesheet) as

.ss05 {
  -moz-font-feature-opentype: "ss05=1" word last;
  font-variant: prince-opentype(ss05);
}

Using the keywords that I proposed. (Note that since one can have a comma sepearated list of features as the value of -moz-font-feature-opentype it is necessary to allow the point of application of the feature to be separately specified for each feature in the list.)

>
>   - personal peeve: I don't like the term "font feature". The term
>     "feature" seems much to generic to be used for a very specific
>     feature (ouch): alternate glyphs.

[SZ] Ouch indeed. Using "font feature" does allow one to correlate with the OpenType specification and "alternate glyph" is just one of the features in that collection. Perhaps one should say "typographic feature" to point out that it is the style of typography being selected (and the role of the font is just to provide the tables that allow that style of typography to be realized). I am not, however, very attached to this suggestion.

[SZ] Steve Zilles

[Jonathan Kew-2]

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?

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.

> 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. (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] 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.)

JK

["Martin J. Dürst"]

Hello Steve, others,

On 2009/10/29 13:27, Stephen Zilles wrote:

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

I'm afraid that toggled would lead to tons of confusion when used with
CSS cascading features. I don't know of any CSS features that are
toggled, for good reasons I think.

Regards,   Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Stephen Zilles]

Comments inline below

Steve Zilles

> -----Original Message-----
> From: Jonathan Kew [mailto:jonathan@...]
> 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.

[John Hudson-4]

Jonathan Kew wrote:

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

It also means that layout options that invoke more than one feature in a
given font technology can be efficiently addressed in mark-up. An
example would be the OTL GPOS optical bounds implementation, which
involves separate features for left and right margins but which would
sensibly be addressed by a single layout tag in a mark-up language.

John Hudson

[Adam Twardoch]

Let me summarize a few important points about how OpenType Layout
features are meant to be used.

I. FEATURE CLASSIFICATION

OpenType Layout features can be divided into various categories, based
on various criteria (see [1] below for more information):

a) "Show in UI": determines whether a certain feature should be somehow
exposed in an application's UI. A different view of seeing this
categorization is whether a certain feature should be user-controllable
or if it should be controlled "behind the scenes" by the OpenType Layout
engine. Obviously, the user-controllable features should have some kind
of exposure through CSS.

b) "Script": indicates a generalization of which features are used with
which scripts (writing systems). Some OpenType Layout features are only
used with some particular scripts, while others are applicable to all
scripts.

c) "Script-specific shaping": the OpenType Layout process is divided
into three phases: before the script-specific shaping, during the
script-specific shaping and after the script-specific shaping. Some
features should be applied to all glyphs before the script-specific
shaping algorithms kick in, others are automatically applied by the
shaping engine during the script-specific shaping, and finally the last
group is applied after the script-specific shaping, and these are
typically the features that are user-controllable.

d) "Applied by default" indicates whether a feature should be applied by
default (while the user may or may not have the opportunity to turn it
off), or should be off by default (in which case the user should have
the opportunity to turn it on).

e) "Functional category": features can be coarsly split into two large
groups: one related to language (features that ensure that a certain
orthographic tradition is followed or even that the text is
orthographically correct at all) and one related to typography (features
that allow the user to select a certain typographic/stylistic treatment).

II. LOOKUP CLASSIFICATION

OpenType Layout features are realized through series of lookups that can
perform two types of actions: substitutions (replacing some glyphs with
others, stored in the OpenType GSUB table) and positioning (adjusting
the width and the x/y position of some glyphs, stored in the GPOS table).

The most important aspect of this is that while most features can be
just turn on and off (i.e. their status is binary), other features may
need an additional feature parameter. For example, if a feature such as
"salt" (stylistic alternates) is realized through GSUB LookupType 3
(alternate substitution, one-to-one-out-of-many), then it is necessary
to specify a numerical parameter that allows to select the alternate out
of the set of alternates.

III. LANGUAGE CLASSIFICATION

All OpenType Layout features are assigned in a context of specific
script and language system. While the assignment of script is easy (the
engine can determine from the Unicode string which script a certain
character belongs to, and from there it can pick the appropriate
OpenType script branch to apply the features for), the language system
is trickier.

As you can see from
http://www.microsoft.com/typography/otspec/languagetags.htm
OpenType uses a list of language systems that do not have a 1:1
correspondence with any of the ISO 639 standards. In OpenType 1.6 (at
the link above), an informational mapping of OpenType language system
tags and "best matches" in the ISO 639 standards has been provided. It
is quite obvious that a web browser that applies OpenType Layout
features should observe the HTML "lang" attribute and, if present, apply
the appropriate features from the particular language system branch in a
font (and only if absent, apply the features from the Default language
system within a script branch). But it might be worth considering to add
a low-level CSS access mechanism to allow users to choose a specific
OpenType language system, because some ISO 639 codes can map to several
OpenType language systems, e.g.

                        (OT)    (ISO)
Chinese Hong Kong   ZHH   zho
Chinese Phonetic ZHP zho
Chinese Simplified ZHS zho
Chinese Traditional ZHT zho

IV. HUMAN-READABLE vs. LOW-LEVEL OT FEATURE ACCESS

I realize that it is of great value to have a mechanism where the most
OpenType Layout features are accessed through human-readable CSS
properties. For some, such as the OpenType "smcp" feature, existing CSS
properties such as "font-variant: small-caps" should be used. For
others, new CSS properties such as those proposed by Jonathan et al.

However, in addition, I think it would be very useful to have a
low-level mechanism to specifically control the OpenType Layout features
directly. See [2] below for some thoughts that I had on that subject.

Best,
Adam

==

[1] Classification of OpenType Layout features, draft by Adam Twardoch:
http://www.twardoch.com/tmp/OpenTypeFeaturesClassification.xls

In the course of discussion in regard to the OpenType 1.5 and 1.6
specification revisions that took place last year, I have circulated a
draft categorization of OpenType Layout features based on some criteria.
The document mentioned above is that draft classification of the
OpenType Layout features that were registered in OpenType 1.5. I also
included the Microsoft-specific MATH engine features that are not
officially part of the OT spec, but I have not yet included the features
added to OpenType 1.6.

The document is an Excel spreadsheet with the following information:

"Tag" and "Friendly name" of all features found in OT 1.5 plus MATH

"Show in UI" which determines whether a certain feature should be
somehow exposed in an application's UI. "no" means that no UI is
necessary, "yes" generally means that a UI element should be exposed
that is directly related to the feature, "special" indicates a special
treatment for the UI, e.g. associating the feature activity with some
general-level application or document preferences (e.g. optical bounds
or CJK orientation).

"UI level" indicates at what level the UI should be implemented: none,
character, word, paragraph, document. Some features are sensibly applied
to just one character or a few, while others can be applied to long runs
of text.

"Script" indicates a generalization of which features are used with
which scripts. This is not 100% accurate, I think it'd be a good idea to
produce an exhaustive mapping of all registered features and mapping
them to all registered script tags. Currently, the OT spec has some
unclear wording e.g. "Indic scripts similar to Devanagari". So the
column sometimes uses script tags and sometimes generic terms like
"ALL", "INDIC", "ARABIC", "RTL". I think that it would be useful to
categorize the OpenType script tag list into such groups (so there is an
exhaustive mapping of which script tags are classified as "European",
"Indic", "Arabetic", "CJK" etc., plus which writing direction they may
have (three columns: LTR, RTL, vert). I'd like to add that to the 2nd
phase of the project.

"Script-specific shaping" is the column that has the actual
classification of when, in relation to script-specific shaping, a
feature is being applied: before the script-specific shaping (I was able
to come up with only four definitive entries for it: ccmp, locl, rtla
and size), during the script-specific shaping, or after the
script-specific shaping. Unfortunately, Adobe follows a different
paradigm of describing their features than Microsoft. I think Adobe's
CJK layout principles would be better off if described in form of a
shaping specification like Microsoft's, rather than spreading it around
the feature description list. Therefore, I have classified all of
Adobe's CJK features as "to be applied after shaping", since "shaping"
is not defined in this context -- though I think it could.

"Applied by default" indicates whether the feature should be always on
by default, never on by default, or whether shaping (or in CJK case,
orientation) determines if the feature is applied.

"Functional category" is just a loose way of classifying the OpenType
Layout features into some categories. There is a major distinction
between "language" and "typography" (there is such distinction in the
script-specific specs already), plus additional subcategorization into
"Asian CJK", "complex scripts", "basic support", "numerals and
scientific", "letter case" and "variants".

==

[2] Notes on a low-level tagging mechanism for OT Layout features in CSS

Below are some notes that I've written to Michael Jansson in 2006 when
he implemented his own extensions to CSS that allowed OpenType Layout
features selection in GlyphGate (this was done through the "text-otl"
CSS property). Now I realize that the particular syntax I proposed below
may not be most conformant to the CSS best practices, so the details of
the syntax might be revised, but I think it'd be rather worthy to have
this kind of mechanism.

The low-level access mechanism for OT Layout features should allow the
document designer to:

1. Explicitly turn OFF certain features (e.g. "-kern")
2. Explicitly call variant numbers in one-to-one-out-of-many
substitutions (e.g. "salt/3")
3. Explicitly specify the writing system of the text by specifying a
script tag (e.g. "latn/liga" vs. "arab/liga").
4. Explicitly specify the language system of the text by specifying a
language tag (e.g. "latn/liga" vs. "latn/TRK/liga").

I believe that all of the above would be useful. The parser should give
a higher priority to the specific OTL script and language tags and only
in their absence, infer the language from the HTML "lang" attribute, and
the script from the Unicode properties of the current text.

I believe my simple syntax that I proposed above would actually be
enough, given the specifics:

* all parts of the tagging are separated by slashes
* there are up to four parts (script/language/feature/variant)
* if there is only one part specified, it is the feature tag; it may be
prefixed with a "-" sign that signifies turning off features that might
be turned on be default;
* if there is more than one part, check the last part; if it is a
integer number, then it is the variant number; disregard this from the
remaining analysis;
* if there is one part, it is the feature tag;
* if there are two parts, the first is the script tag (which can be
"DFLT", all in uppercase, or otherwise can be a lowercase-only string of
four letters), the second the language, the third the feature.
* if there are three parts, the first is the script tag, the second is
the language tag, the third the feature tag.

Examples:
text-otl:liga
text-otl:-ccmp
text-otl:latn/salt/4
text-otl:latn/TRK/liga
text-otl:cyrl/SRB/locl
text-otl:DFLT/ornm/6

==

["Martin J. Dürst"]

Hello Adam,

[cc to IETF LTRU WG]

On 2009/10/30 16:12, Adam Twardoch (List) wrote:

> III. LANGUAGE CLASSIFICATION
>
> All OpenType Layout features are assigned in a context of specific
> script and language system. While the assignment of script is easy (the
> engine can determine from the Unicode string which script a certain
> character belongs to, and from there it can pick the appropriate
> OpenType script branch to apply the features for), the language system
> is trickier.
>
> As you can see from
> http://www.microsoft.com/typography/otspec/languagetags.htm
> OpenType uses a list of language systems that do not have a 1:1
> correspondence with any of the ISO 639 standards. In OpenType 1.6 (at
> the link above), an informational mapping of OpenType language system
> tags and "best matches" in the ISO 639 standards has been provided. It
> is quite obvious that a web browser that applies OpenType Layout
> features should observe the HTML "lang" attribute and, if present, apply
> the appropriate features from the particular language system branch in a
> font (and only if absent, apply the features from the Default language
> system within a script branch). But it might be worth considering to add
> a low-level CSS access mechanism to allow users to choose a specific
> OpenType language system, because some ISO 639 codes can map to several
> OpenType language systems, e.g.
>
>                          (OT)    (ISO)
> Chinese Hong Kong   ZHH   zho
> Chinese Phonetic ZHP zho
> Chinese Simplified ZHS zho
> Chinese Traditional ZHT zho

HTML lang and XML xml:lang use BCP 47 (http://tools.ietf.org/html/bcp47,
formerly RFC 1766/3066/4646) tags, not ISO 639 directly. BCP 47 uses
two-letter codes (i.e. 'zh') and not three-letter codes (i.e. 'zho')
when two-letter codes are available. Also, BCP 47 has facilities for
indicating Region (country,...) with two-letter codes and for indicating
script with four-letter codes. So the above list should be changed to:

                         (OT)    (BCP 47)
Chinese Hong Kong   ZHH   zh-HK
Chinese Phonetic ZHP **
Chinese Simplified ZHS zh-Hans
Chinese Traditional ZHT zh-Hant

** not sure what's meant by Chinese Phonetic, may be zh-Latn (Latin
transcription) or zh-Bopo (Bopomofo)?

Regards,   Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Bert Bos]

Stephen Zilles wrote:

> Comments inline below
>
> Steve Zilles
>
>> -----Original Message-----
>> From: Jonathan Kew [mailto:jonathan@...]
>> 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.

Yes, we should choose names that match the style of the other keywords
in CSS. No need to copy the naming style of OpenType or other font formats.

Moreover, I don't think it is a requirement that CSS supports all OT
features. A handful of the more common ones is enough. If a designer
wants a specific feature of a specific font, he can make a new font (or
a virtual font) in which that feature is turned on. That's what we have
 @font-face for.

We don't provide ways either to replace colors in a JPEG or change a
circle to a square in an SVG. The designer just makes a new image with a
new URL. That's a more flexible and modular solution.

I think we should provide keywords for small caps (already done) and
oldstyle figures, and maybe one or two more. But if a font has half a
dozen different ampersands and the designer really wants the fourth
variant, he should make a font with that glyph. (Or maybe he actually
meant to use an image?)



Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@...                             2004 Rt des Lucioles / BP 93
  [phone]            06902 Sophia Antipolis Cedex, France

[Sylvain Galineau]

> From: www-font-request@... [mailto:www-font-request@...] On
> Behalf Of Bert Bos


 
> Moreover, I don't think it is a requirement that CSS supports all OT
> features. A handful of the more common ones is enough. If a designer
> wants a specific feature of a specific font, he can make a new font (or
> a virtual font) in which that feature is turned on. That's what we have
>  @font-face for.

Do you mean that @font-face would support a mapping mechanism e.g. (apologies for bad names/patterns)

@font-face {
        font-family:Greetings;
        src:url(Greetings.xyz);
        font-variant-map: exalted feature("salt=2","ss05=1");
}

...

#headline {
        font-family:Greetings;
        font-variant: exalted;
}

[Mark Davis ☕]

Agreed.

I'm guessing he meant zh-Latn-pinyin

(http://www.iana.org/assignments/language-subtag-registry)

Mark

On Fri, Oct 30, 2009 at 02:29, "Martin J. Dürst" <duerst@...> wrote:

Hello Adam,

[cc to IETF LTRU WG]

On 2009/10/30 16:12, Adam Twardoch (List) wrote:

III. LANGUAGE CLASSIFICATION

All OpenType Layout features are assigned in a context of specific
script and language system. While the assignment of script is easy (the
engine can determine from the Unicode string which script a certain
character belongs to, and from there it can pick the appropriate
OpenType script branch to apply the features for), the language system
is trickier.

As you can see from
http://www.microsoft.com/typography/otspec/languagetags.htm
OpenType uses a list of language systems that do not have a 1:1
correspondence with any of the ISO 639 standards. In OpenType 1.6 (at
the link above), an informational mapping of OpenType language system
tags and "best matches" in the ISO 639 standards has been provided. It
is quite obvious that a web browser that applies OpenType Layout
features should observe the HTML "lang" attribute and, if present, apply
the appropriate features from the particular language system branch in a
font (and only if absent, apply the features from the Default language
system within a script branch). But it might be worth considering to add
a low-level CSS access mechanism to allow users to choose a specific
OpenType language system, because some ISO 639 codes can map to several
OpenType language systems, e.g.

                        (OT)    (ISO)
Chinese Hong Kong       ZHH     zho
Chinese Phonetic        ZHP     zho
Chinese Simplified      ZHS     zho
Chinese Traditional     ZHT     zho

HTML lang and XML xml:lang use BCP 47 (http://tools.ietf.org/html/bcp47, formerly RFC 1766/3066/4646) tags, not ISO 639 directly. BCP 47 uses two-letter codes (i.e. 'zh') and not three-letter codes (i.e. 'zho') when two-letter codes are available. Also, BCP 47 has facilities for indicating Region (country,...) with two-letter codes and for indicating script with four-letter codes. So the above list should be changed to:

                       (OT)    (BCP 47)
Chinese Hong Kong       ZHH     zh-HK
Chinese Phonetic        ZHP     **
Chinese Simplified      ZHS     zh-Hans
Chinese Traditional     ZHT     zh-Hant

** not sure what's meant by Chinese Phonetic, may be zh-Latn (Latin transcription) or zh-Bopo (Bopomofo)?

Regards,   Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...
_______________________________________________
Ltru mailing list
Ltru@...
https://www.ietf.org/mailman/listinfo/ltru

[Bert Bos]

On Friday 30 October 2009, Sylvain Galineau wrote:

> > From: www-font-request@... [mailto:www-font-request@...] On
> > Behalf Of Bert Bos
> >
> > Moreover, I don't think it is a requirement that CSS supports all
> > OT features. A handful of the more common ones is enough. If a
> > designer wants a specific feature of a specific font, he can make a
> > new font (or a virtual font) in which that feature is turned on.
> > That's what we have @font-face for.
>
> Do you mean that @font-face would support a mapping mechanism e.g.
> (apologies for bad names/patterns)
>
> @font-face {
> font-family:Greetings;
> src:url(Greetings.xyz);
> font-variant-map: exalted feature("salt=2","ss05=1");
> }
>
> ...
>
> #headline {
> font-family:Greetings;
> font-variant: exalted;
> }

I thought at first about moving the font features from
the 'font-variant' property to a descriptor inside @font-face, but I
actually prefer now to not have them there either.

This should be handled outside of CSS, with a program such as Fontforge
or maybe a format such as the proposed WOFF. That not only makes the
font features available in contexts where you don't have or want CSS,
such as XSL, SVG, PDF or TeX, but it also avoids complexity in CSS and
a dependency of CSS on a particular font format.

When I wrote "virtual font," I indeed had a scheme in mind to turn
@font-face into a language for defining virtual fonts. A standard for
virtual fonts could be nice. But on second thoughts, it's only useful
if that standard *doesn't* depend on CSS.



Bert
--
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@...                             2004 Rt des Lucioles / BP 93
  [phone]            06902 Sophia Antipolis Cedex, France

[Chris Lilley]

On Friday, October 30, 2009, 4:42:01 PM, Bert wrote:

BB> On Friday 30 October 2009, Sylvain Galineau wrote:
>> Do you mean that @font-face would support a mapping mechanism e.g.
>> (apologies for bad names/patterns)

>> @font-face {
>>       font-family:Greetings;
>>       src:url(Greetings.xyz);
>>       font-variant-map: exalted feature("salt=2","ss05=1");
>> }

>> ...

>> #headline {
>>       font-family:Greetings;
>>       font-variant: exalted;
>> }

BB> I thought at first about moving the font features from
BB> the 'font-variant' property to a descriptor inside @font-face, but I
BB> actually prefer now to not have them there either.

I disagree. The features need to be in a font descriptor, so that the
layout engine can download fonts with the appropriate features.

BB> This should be handled outside of CSS, with a program such as Fontforge
BB> or maybe a format such as the proposed WOFF. That not only makes the
BB> font features available in contexts where you don't have or want CSS,
BB> such as XSL, SVG, PDF or TeX,

SVG uses, and XSL will use, an XML serialisation of the CSS
@font-face. So putting these features in a descriptor makes them
available to HTML/CSS, to SVG, and soon to XSL.

As to PDF or TeX I have no opinion.

BB> but it also avoids complexity in CSS and
BB> a dependency of CSS on a particular font format.

That concern has already been addressed.
On Thursday, October 29, 2009, 6:04:52 AM, Jonathan wrote:

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

On Friday, October 30, 2009, 4:42:01 PM, Bert wrote:

BB> When I wrote "virtual font," I indeed had a scheme in mind to turn
BB> @font-face into a language for defining virtual fonts.

That is already part of the design for @font-face. Its applicability
to the task was suggested to me at a Unicode conference, by one Donald
Knuth, whose ideas are worth taking seriously :)

BB>  A standard for
BB> virtual fonts could be nice. But on second thoughts, it's only useful
BB> if that standard *doesn't* depend on CSS.

Eh, I don't think you have demonstrated that.



--
 Chris Lilley                    mailto:chris@...
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

[John Hudson-4]

Martin J. Dürst wrote:

> HTML lang and XML xml:lang use BCP 47 (http://tools.ietf.org/html/bcp47,
> formerly RFC 1766/3066/4646) tags, not ISO 639 directly....

It should be noted that 'language system' in the context of OpenType
Layout is a misnomer, because that these tags actually represent are
typographic conventions -- most obviously, culturally preferred glyph
shapes --, which are very often identified with language use but not
always or necessarily. This is why OTL language system tagging does not
use one of the two or three letter language code standards: the
expectation was always that some sets of typographic conventions would
not be mappable to languages or, as Adam notes, to might map to multiple
languages, or, indeed, that some users of a particular language would
want to employ 'language system' conventions of another language.

I agree with Adam that it is desirable to have a mechanism to directly
address OTL language system tags for display independent of language
tagging of content.

JH

[John Daggett]

Bert Bos wrote:

> I think we should provide keywords for small caps (already done) and
> oldstyle figures, and maybe one or two more. But if a font has half
> a dozen different ampersands and the designer really wants the
> fourth variant, he should make a font with that glyph. (Or maybe he
> actually meant to use an image?)

This is far too limiting in my opinion.  There are many valuable features in OpenType, we should definitely attempt to expose ones that are useful for authors and commonly supported in fonts.  Authors should be able to vary their use of these features within a page, asking authors to fiddle with font editors to produce a font that enables certain features is error prone, difficult, not to mention a violation of "no alteration" clauses of many font licenses.

Steve Zilles wrote:

> I meant that CSS would use the long names and implementers would use
> the registry to find the related OT tag value.

To some degree, the issue of whether to expose low-level OpenType features is a distraction right now.  We implemented -moz-font-feature-opentype as a way of exposing features easily for experimentation purposes since many of these features are better understood visually.  The most important thing to focus on now is what set of properties is a good middle point between Bert's two feature addition and a set of properties that exposes every OpenType feature ever proposed.

Chris Lilley wrote:

> BB> I thought at first about moving the font features from
> BB> the 'font-variant' property to a descriptor inside @font-face, but I
> BB> actually prefer now to not have them there either.
>
> I disagree. The features need to be in a font descriptor, so that
> the layout engine can download fonts with the appropriate features.

I think adding a font-variant descriptor to @font-face is extremely useful, since many OpenType features have values that are font specific (e.g. the meaning of the styleset features ss01, ss02, etc.).  I *don't* think it should be used as part of font selection however, e.g. selecting a face based on the value of font-variant.  That's old school thinking. ;)

Cheers,

John Daggett
Mozilla Japan

[fantasai]

Bert Bos wrote:

>
> Yes, we should choose names that match the style of the other keywords
> in CSS. No need to copy the naming style of OpenType or other font formats.
>
> Moreover, I don't think it is a requirement that CSS supports all OT
> features. A handful of the more common ones is enough. If a designer
> wants a specific feature of a specific font, he can make a new font (or
> a virtual font) in which that feature is turned on. That's what we have
>  @font-face for.
>
> We don't provide ways either to replace colors in a JPEG or change a
> circle to a square in an SVG. The designer just makes a new image with a
> new URL. That's a more flexible and modular solution.
>
> I think we should provide keywords for small caps (already done) and
> oldstyle figures, and maybe one or two more. But if a font has half a
> dozen different ampersands and the designer really wants the fourth
> variant, he should make a font with that glyph. (Or maybe he actually
> meant to use an image?)

I agree with Bert's position here. For a lot of these less common features
(and by common, I mean common to fonts, not just commonly used), the values
and their appropriateness is very font-specific. That says to me that it
should be in the @font-face rule. Triggering alternate glyph set #2 when you
have no guarantee of what font ultimately gets used seems like a good way
to introduce cross-platform problems.

~fantasai