Re: @font-face and unicode-range

Hi Michael,

> Recently we have been updating Prince so that @font-face rules are
> handled as described in the latest draft of the CSS3 Fonts module and
> we have also added support for the unicode-range descriptor.

Great, fantastic!

> - Should the spec include keywords for common Unicode blocks?
> 
> The TrueType OS/2 table includes a UnicodeRange field that describes
> the coverage of several common Unicode blocks, eg. basic_latin,
> latin1_supplement, greek_and_coptic, and so on. Something like this
> could be a useful addition to the spec that would make it easier for
> authors than writing explicit codepoint ranges.

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

unicode-range: "Basic Latin", U+1??;

The list of ranges in the OS/2 table seems to be based on named ranges
in the Unicode standard, I'll see if I can find a definitive source for
this.

>   - Is it worth allowing single character strings to identify codepoints?
> 
> For example, 'a' or '\61' could be used as a synonym for U+61. This
> might be easier for people familiar with CSS syntax. It doesn't help
> with the other ranges though, unless 'a'-'z' is also allowed.

Makes sense but I think the implementation details could easily get a
bit hairy, you would end up with ambiguous situations involving things
like combining diacritics and shaped vowels.  To authors they would
appear as a single character but underneath they would in fact be
multi-character strings:

  unicode-range: 'å'; /* could be a-ring or 'a' followed by ring diacritic */
  
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.

>   - Is there a need for a "language" descriptor in @font-face rules?
> 
> This might be an internal property only needed by vendors and not
> authors, but it seems useful to have a descriptor to distinguish
> particular font faces by language. This could include providing a
> single font to handle traditional and simplified Chinese:
> 
> @font-face {
>      font-family: MyChineseFont;
>      src: url("simpl.ttf");
>      language: zh, zh-CN
> }
> 
> @font-face {
>      font-family: MyChineseFont;
>      src: url("trad.ttf");
>      language: zh-HK, zh-TW
> }

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?

If this is more for documentation purposes, wouldn't a comment suffice?

> The only other way to do this at present is using the :lang()
> selector, but that can be difficult to integrate cleanly with other
> CSS rules and uses of the font and font-family properties.

This is interesting, could you elaborate more on this?

Cheers,

John Daggett
Mozilla Japan

Received on Monday, 1 June 2009 07:26:31 UTC