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

Re: Unicode Normalization

From: Robert J Burns <rob@robburns.com>
Date: Thu, 5 Feb 2009 01:06:05 -0600
Cc: Anne van Kesteren <annevk@opera.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, public-i18n-core@w3.org, jonathan@jfkew.plus.com, W3C Style List <www-style@w3.org>
Message-Id: <9B6ADF28-41EF-453C-A620-882AFE0B3287@robburns.com>
To: benjo316@gmail.com
Hi Benjamin,

On Feb 4, 2009, at 9:17 PM, Benjamin wrote:

> On Wed, Feb 4, 2009 at 3:07 PM, Robert J Burns <rob@robburns.com>  
> wrote:
>
> 〈this string〉
> 〈this string〉
> 〈this string〉
>
>
> When I copied the three strings to a text editor it did not change  
> the characters; they remained the same.

Same for me, These byte-wise distinctions have been preserved round- 
trip from sending it to the list and getting back in replies. But it  
wouldn't surprise me that John Kew is finding different results (since  
normalizing those characters is permitted by Unicode)

> Also, I can see a difference between the characters; The two  
> brackets at the top and the one on the bottom left are duller, while  
> the other three are sharper. This difference is apparent in both the  
> browser and the text editor(Not sure if it matters, though).

I would say that is a bug in your font. Fonts, by using separate  
glyphs for canonically equivalent characters, contribute to the  
confusion authors face when creating content. The glyph distinctions  
lead authors to treat the characters semantically distinct (which  
shouldn't happen). Fonts play an important role in this (on par with  
input systems) since the fonts control the glyphs used. For example if  
a font uses the same glyphs for "½" as the font maker uses for the  
compatibility equivalent sequence "1⁄2", this helps with Unicode  
authoring. It is remarkable how few font makers take minimal amount of  
time necessary to do this. This is a similar problem to font/glyph  
issues outlined earlier by Andrew Cunningham with various African and  
Eastern languages.

My feeling is that these are the types of things we should NOT be  
expecting authors to deal with. The font makers should spend the extra  
time to understand these issues and design their fonts accordingly.  
The input system software developers should do the same. The parsers  
for XML, HTML, CSS, Javascript and so on should normalize strings in a  
way that authors never have to think about these issues with Unicode.

Take care,
Rob
Received on Thursday, 5 February 2009 07:06:45 GMT

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