[Webkit-unassigned] [Bug 22339] Support Indian web sites with EOT by on-the-fly transcoding to Unicode

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=22339





------- Comment #15 from darin at apple.com  2009-02-25 14:39 PDT -------
(In reply to comment #14)
> > In general, names for Unicode characters should go into the CharacterNames.h
> > header and should be the names from the Unicode specification, without any runs
> > of all capital letters. For example: copyrightSign.
> 
> Some of them in this patch are real Unicode character names while others are
> not. For instance, the following line :
> 
>    static const UChar comboZHUU = 0x00E8;

Yes, those should not go in CharacterNames.h.

> > Requiring a particular host name seems like a bad idea. I think the font name
> > should be enough. Did we already discuss this?
> 
> We have discussed this before. In a sense, it's a policy issue.
> 
> I believe font names are sufficiently unique to identify corresponding font
> encodings without a host name. For instance, when fontFoo was converted to a
> real Unicode-based font, its name is usually changed, too (like fontFoo_U or
> something like that). And, I haven't seen two Indic font-encoded fonts with the
> same name but with different 'font encodings' (but, that does not mean that
> there are none).
> 
> On the other hand, we do not want this convention (of using 'font-encoded
> fonts') to spread further than where they're used now. Using (font, host) pairs
> as keys rather than font alone would limit our support to a finite set of
> sites.

Given this justification, I'd prefer to omit the host name rule. I don't think
that our browsers' behavior will be sufficient to affect the website developers
behavior unless we had much larger market share.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.