W3C home > Mailing lists > Public > www-style@w3.org > October 2009

Re: font features in CSS

From: Chris Lilley <chris@w3.org>
Date: Fri, 30 Oct 2009 17:08:34 +0100
Message-ID: <175834252.20091030170834@w3.org>
To: Bert Bos <bert@w3.org>
CC: "www-font@w3.org" <www-font@w3.org>, "www-style@w3.org" <www-style@w3.org>
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@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Friday, 30 October 2009 16:08:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:30 UTC