Re: @font-face and unicode-range

Hi John,

> This is a good improvement I think but maybe it would be better to just
> add a string value to the possible values of <urange>.

That's a good idea. The definitive source for Unicode block names would 
be the Blocks.txt file, eg. for Unicode 5.1:

http://unicode.org/Public/UNIDATA/Blocks.txt

It also includes some rules about matching block names, stating that 
casting, whitespace, hyphens, and underscores are all ignored, which 
seems reasonable.

> You could probably come up with rules to reduce possible ambiguity but I
> think the complexity here would outweigh the potential convenience. 
> With the named ranges you describe above I think you would cover most of
> the use cases for shorthand notation like this.

Good point, the single character syntax doesn't seem worth it.

> I understand the problem you're considering here, it occurs in many
> languages that share a common script, but I'm unclear if there's a
> possible solution here. One way to use the above notation might be to
> select different faces within a family for a given Unicode range based
> on which language matches the language of the page.  The default value
> would be 'all' and if the current page language didn't match a language
> in the list, another face would be selected?

More or less yes, although the language might be for a subset of the 
page, eg. a paragraph or a quote with a lang attribute:

<p>
In simplified Chinese the character for bone has a stroke on the left:
<q lang="zh-Hans">骨</q> while the traditional character has a stroke on 
the right: <q lang="zh-Hant">骨</q>.
</p>

This use case can be handled with regular language selectors:

q:lang(zh-Hans) { font-family: AR PL KaitiM GB }
q:lang(zh-Hant) { font-family: AR PL KaitiM Big5 }

However it is a useful abstraction to be able to define unified fonts in 
CSS that cover multiple languages as well as scripts, which requires a 
language descriptor in @font-face rules. Without this one can end up 
with an increased number of styling rules, eg. the product of the number 
of fonts (heading, body text, sidenote) with the number of languages:

h1 { font-family: MyHeadingFont }
h1 *:lang(zh) { font-family: MyChineseHeadingFont }

p { font-family: MyTextFont }
p *:lang(zh) { font-family: MyChineseTextFont }

In this example it would be convenient to create unified fonts for 
headings and body text that supported multiple languages.

If this isn't sufficient justification, we would be happy implementing 
it as a vendor-specific property, which we would use to support the 
definition of the default "serif" and "sans-serif" font families in our 
default style sheets, which should support all scripts and languages.

Cheers,

Michael

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

Received on Monday, 1 June 2009 08:18:55 UTC