W3C home > Mailing lists > Public > www-style@w3.org > January 2008

RE: Advanced Font Features

From: Sergey Malkin <sergeym@windows.microsoft.com>
Date: Tue, 22 Jan 2008 04:06:35 -0800
To: www-style <www-style@w3.org>
Message-ID: <E30895F8BA39B6439F5F1AAA1DBBFB524711035A59@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>

(I am catching up with this discussion, this mail is rather long tryng to comment on important issues from all previous messages on the thread)

Christoph wrote:

> There are several levels of ligation indeed, and for normal users those are
> probaby enough. Finer control is necessary for expert use of course, but I'm
> not sure whether simple string lists are sufficient and whether they should be
> in CSS itself or combined with dictionary files.

When we were designing WPF typography properties, general approach was to look at all registered OpenType features, find ones that make sense to give user ability to control and assign separate property to it (sometimes merging few mutually exclusive features into enums). We intentionally did not want to control how they are used, leaving it to the client. Since then my opinion changed a bit. If you want to provide low level control, just allow client to specify custom 4-letter tags. But for user agents that want to provide set of typographic features that make sense in real life, even full set of features exposed in WPF is too much. I would probably even deprecate some features in OpenType itself because they make situation confusing for everybody: application developers, application users and font designers.

> There are standard |liga|, contextual |clig|, discretionary |dlig|, historical |hlig|

This is an example of what I am talking about. For discretionary and historical ligatures, I am not sure anybody can clearly define what each of them mean exactly and which feature particular ligature glyph should go to. In this particular case, even Adobe (that paying close attention to the needs of typographers) is not distinguishing between historical and discretionary calling them extended and providing single checkbox to turn both of them on or off.

Contextual ligatures is a very strange thing too. I believe that contextual alternates <calt> feature is covering purpose of contextual ligatures. Since some contextual forms may not be possible without forming a ligatures, it is very hard to distinguish between them. So, single property named "contextual forms" should be enough. Swashes are similar: contextual swashes can be split between simple swashes and contextual forms properties, there is no need for separate property.

> and required |rlig| ligatures possible in Open Type, as well as several "diacritic"
> ligatures for complex (esp. Indic) scripts, e.g. |abvs/blwf/pres/psts/vatu|.

Required ligatures and Indic substitution features should not be controllable by client at all. They are meant to be controlled by particular script engine to ensure proper script behavior. If client starts messing with them, script will fall apart, so exposing them through CSS properties is wrong.

>   acronym {font-variant-caps: smallcaps  /* c2sc wanted */}
>   acronym {font-variant-caps: petitecaps /* c2pc wanted */}
>   .author {font-variant-caps: smallcaps  /* smcp wanted */}
>   .author {font-variant-caps: petitecaps /* pcap wanted */}

I agree that capitals control should be finer that just small caps. Beyond listed here, titling feature is also a good value of caps property to include into CSS. It would de frequently used for :firstletter, for example.

Btw, I think you meant "acronym { font-variant-caps: allsmallcaps; }" and this would imply both <c2sc> and <smcp> features applied.

> Despite the analog name I think unicase |unic| would belong here to, not in |text-transform|.

Absolutely agree. Algorithmic implementation will be ugly and of course it won't take care of globalization issues, even simple Latin extended character sets.

> You said in a followup message this would primarily be used for digits,
> but what if a font has a full-featured monospace variant?
> There are font families that include serif and sans-serif variants, some even semi-serif ones.
also Philip wrote:
> Isn't "-variant" redundant, and wouldn't "-spacing" be better than "-space" ?

"Monospace" and serif/sans-serif are features of the font family (possibly within extended family), not particular glyph style within a font. Font-variant-* properties should not be used as a font selector mechanism. Confusion and desire to put additional meaning into them may be because of the property name itself. There must be something better describing the nature of typographic properties. I would still keep all typographic features under one single prefix, but I can't think of a better name right now.

> Although these are still put in separate files, you might consider combining
> their selection with that of swashes, because they are really only very large serifs.

This may be not relevant to this discussion, but you are absolutely wrong! Serifs is a core property of the font style intended to keep glyphs lined up, not to put additional decoration around it.

> Does this include fractions?

Fractions make sense to include, they are frequently used and well defined.

> There should be at least another property for selecting alternate / historical
> / localised forms, but I don't know what its values would be (and how they would
> map to OT features).

Alternate forms are in the area of very fine control. They usually require control on particular character. This may be possible to express in CSS, but will be pain to use. There is better mechanism in OpenType for this purpose, which is stylistic sets (ss01-ss20). This is very interesting and powerful area people just start really exploring. Stylistic sets are definite candidates to include into CSS.

Localized forms should not be controlled directly as they are defined by language, not user preferences. It should be applied by layout engine automatically, along with required ligatures, mark positioning, and few other mandatory features required for proper script shaping.

Håkon wrote:

> I think this may be a general problem facing us as we venture into new font
> features: the number of fonts that support these new features are limited,
> and not many users have access to them.

We should not limit us by the fact of limited typographic support in current browsers.
Those are features used in real typography, they are proven to be working and are
implemented in other(non CSS) text layout engines, e.g. some Adobe products and WPF.

Fantasai wrote:

> Wouldn't it make sense to use the font-variant-digits property for that switch?
> Switching between proportional and monospace for the whole font has different
> implications for non-Western scripts. e.g. while most Japanese fonts are
> monospaced, quite a few have proportional glyphs for kana.

Agreed, this feature is clearly targeting digits (and surrounding punctuation characters). As for proportional Kana, Adobe has just registered special feature exactly for this purpose.

Received on Tuesday, 22 January 2008 12:06:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC