W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css3-fonts] font selection for Unicode Variation Selector

From: Asmus Freytag <asmusf@ix.netcom.com>
Date: Sat, 26 Feb 2011 12:00:48 -0800
Message-ID: <4D695BF0.90508@ix.netcom.com>
To: Jonathan Kew <jonathan@jfkew.plus.com>
CC: John Daggett <jdaggett@mozilla.com>, www-style@w3.org, John Hudson <tiro@tiro.com>, public-i18n-cjk@w3.org, www-international@w3.org, Koji Ishii <kojiishi@gluesoft.co.jp>
On 2/25/2011 1:07 AM, Jonathan Kew wrote:
> Koji-san would like [users] to be able to say something like
>    font-family: 'My Favorite Font', 'My Special IVS Font';
>
> where 'My Special IVS Font' provides glyphs for IVS sequences that are not supported in 'My Favorite Font', but he does not want to switch the entire text to the 'Special IVS' font (perhaps it doesn't even support all the same standard Unicode characters as the 'Favorite' one).

There are multiple levels of this. The scenario extends:

  font-family: 'My Favorite Font', 'Some generic font', 'Special IVS Font', 'Generic IVS Font';


> Rather than treating IVS sequences as a special case, though, I wonder whether it would be better to specify that the font matching algorithm should operate at the level of default grapheme clusters, not individual characters
This is a reasonable approach. For IVS the whole sequence would be in 
one font (because the selector characters don't have glyphs), and for 
combining marks, in most cases it makes no sense to apply a mark from 
one font to a base character from another.

I can think of some weird exceptions, but the results, even if 
implementations supported that, would likely be rather haphazard. Layout 
engines usually divide things into font runs to begin with and then 
apply layout, making grapheme clusters that have a font run boundary not 
very useful or workable.

> (falling back to individual-character matching only if no font is available that supports the complete cluster). In general, it seems undesirable for a font change to occur within a default grapheme cluster (e.g. between a base character and an associated diacritic); it would be better to render the entire cluster using a font that supports all its components.

Correct.

On 2/26/2011 11:11 AM, John Hudson wrote:
>
>
> Recently, there has been ISO movement on standardising a composite 
> font format, i.e. a mechanism to define virtual fonts from collections 
> of individual fonts, specifying which component fonts should be used 
> for which characters. There are limits to the typographic 
> sophistication of such an approach that will require fairly careful 
> use of the mechanism (layout features will not apply across component 
> font boundaries). But it seems to me that something like this could 
> provide a solution to the problems you have raised.

In this context, the way a CSS statement like

  font-family: 'My Favorite Font', 'Some generic font', 'Special IVS Font', 'Generic IVS Font';

ought to work is that it sets up a composite font selection on the fly.

Each grapheme cluster would then be rendered at the first font 
encountered that is able to render it.

I've used my own composite font mechanism for decades as part of the 
process of printing the Unicode code charts. For that application it's 
particularly nice to be able to pretend that one has a single "Unicode 
font". From that experience I know that performance issues can be 
tackled successfully (our composite fonts contain hundreds of entries).

A./
Received on Saturday, 26 February 2011 20:04:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT