W3C home > Mailing lists > Public > www-style@w3.org > September 2013

RE: [css-fonts-3] i18n-ISSUE-296: Usable characters in unicode-range

From: Phillips, Addison <addison@lab126.com>
Date: Tue, 17 Sep 2013 04:41:42 +0000
To: John Daggett <jdaggett@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>
CC: Richard Ishida <ishida@w3.org>, W3C Style <www-style@w3.org>, "www International" <www-international@w3.org>
Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB5170EF0FD@ex10-mbx-36006.ant.amazon.com>
I tend to agree: this is an existing syntax. I don't seen any issues with the accuracy of the existing text. One might have argued with the syntax back in v2.1 days, but I don't see a reason to make a change at this juncture.

Addison

> -----Original Message-----
> From: John Daggett [mailto:jdaggett@mozilla.com]
> Sent: Monday, September 16, 2013 6:56 PM
> To: Anne van Kesteren
> Cc: Phillips, Addison; Richard Ishida; W3C Style; www International
> Subject: Re: [css-fonts-3] i18n-ISSUE-296: Usable characters in unicode-range
> 
> 
> After re-reading all the posts on this issue, at this point I don't think I see an
> issue that requires further consideration.  The use of "valid Unicode codepoint"
> has been removed from the description of 'unicode-range' in the editor's draft.
> 
> In particular, I think Anne's point about surrogate handling [1] is completely
> orthogonal to the behavior of unicode-range:
> 
> > It seems weird to say it expresses a range of Unicode scalar values
> > and then include U+D800 to U+DFFF in that range. And let's not use
> > "characters" as that's a confusing term. Saying that the range is in
> > code points but U+D800 to U+DFFF are ignored (rather than treated as
> > an error) could make sense.
> 
> Non-Unicode encoding and surrogate handling issues are dealt with in levels
> above the level where font matching occurs.  If you look carefully at the
> description of font matching, the range of codepoints defined by the 'unicode-
> range' descriptor is intersected with the underlying character map of the font.
> *That* is what defines the exact set of codepoints that are matched as part of
> the font matching algorithm. Given that no font ever includes mappings for
> surrogate codepoints to glyphs and no layout engine ever treats lone surrogates
> as individual codepoints, I don't see the need to adjust the definition of
> 'unicode-range'.  Invalid codepoints like this will naturally be ignored given the
> existing definition of font matching.
> 
> Regards,
> 
> John Daggett
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2013Sep/0318.html

Received on Tuesday, 17 September 2013 04:43:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC