Closed
Bug 223653
Opened 21 years ago
Closed 19 years ago
[Xft] support localized font family name
Categories
(Core Graveyard :: GFX: Gtk, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jshin1987, Assigned: jshin1987)
References
Details
(Keywords: intl)
Attachments
(2 files, 1 obsolete file)
1.04 KB,
text/html
|
Details | |
6.35 KB,
patch
|
blizzard
:
review+
rbs
:
superreview+
asa
:
approval1.8a6+
|
Details | Diff | Splinter Review |
At the moment, this is just a place holder because this bug depends on fontconfig which doesn't yet offer a way to retrieve localized font names for UI and font matching. Numerous web sites in CJK countries use localized font family names in CSS [1] so that Mozila have to match them against fonts available on the system. In addition, the font selection menu needs to give localized names corresponding to the current locale (i.e. Korean names under Korean locale if available) [1] There's an evangelisim issue here. Because not all web browsers can understand localized font names, web page authoers in CJK countries should list a single font twice ( Non-ASCII name and ASCII-only name) in CSS.
Assignee | ||
Comment 1•21 years ago
|
||
fontconfig bug I've just filed : http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=171
Assignee | ||
Comment 2•20 years ago
|
||
http://firefly.idv.tw/setfont-xft/patches/mozilla/mozilla-1.6-xft_cjkfamilyname-20040117.patch This patch, by itself, doesn't work. fontconfig should be fixed as well. See http://firefly.idv.tw/setfont-xft/patches/fontconfig/fontconfig-2.2.92-multifamily-20031217.patch
Fontconfig has been (partially) fixed. It now presents all available names to the application. But, mozilla is now confused by the UTF-8 names it sees, displaying garbage instead of the correct name. I assume it doesn't know what encoding the font names are presented in; fontconfig takes some care to present them in UTF-8 only.
Assignee | ||
Comment 4•20 years ago
|
||
Keith, it's fixed on fontconfig CVS, right? I'll grab it sometime soon and work on Mozilla's side to take advantage of.
Fontconfig 2.2.97 has support for multi-lingual names. You can find that release at http://fontconfig.org. This was released yesterday, so CVS is identical at the present hour. Use either; you'll be among the first on your block. Because Mozilla boldly uses the first name in each font, most names work just fine; TrueType fonts almost always place an English name first. I have one font (MS ゴシック,MS Gothic) which places a Japanese name first. For this font, Mozilla presents me with (I think) "￯ᄐᆳ￯ᄐᄈ  ̄ツᄡ ̄ツᄋ ̄テテ ̄ツᆵ" or perhaps "￯ᄐᆳ￯ᄐᄈ ₩リホ₩ワン". Presumably, this is just a misunderstanding of the encoding used for font names, although Fontconfig has long specified that all strings are in UTF-8 encoding.
Assignee | ||
Comment 6•20 years ago
|
||
Thanks. reposting of comment #5 (with the character encoding set to UTF-8 in Mozilla) Because Mozilla boldly uses the first name in each font, most names work just fine; TrueType fonts almost always place an English name first. I have one font (£Í£Ó «´«·«Ã«¯,MS Gothic) which places a Japanese name first. For this font, Mozilla presents me with (I think) "￯ᄐᆳ￯ᄐᄈ £þツᄡ£þツᄋ£þテテ£þツᆵ" or perhaps "￯ᄐᆳ￯ ᄐᄈ£Üリホ£Üワン". Presumably, this is just a misunderstanding of the encoding used for font names, although Fontconfig has long specified that all strings are in UTF-8 encoding.
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•20 years ago
|
||
sorry for spamming. The encoding was not set to UTF-8 when posting comment #6. Because Mozilla boldly uses the first name in each font, most names work just fine; TrueType fonts almost always place an English name first. I have one font (MS ゴシック,MS Gothic) which places a Japanese name first. For this font, Mozilla presents me with (I think) "ᄐᆳᄐᄈ  ̄ツᄡ ̄ツᄋ ̄テテ ̄ツᆵ" or perhaps "ᄐᆳ ᄐᄈ₩リホ₩ワン". Presumably, this is just a misunderstanding of the encoding used for font names, although Fontconfig has long specified that all strings are in UTF-8 encoding.
Assignee | ||
Comment 8•20 years ago
|
||
I've got a patch (but I couldn't make a diff because I can't access cvs.mozilla.org due to some firewall set-up mistake on my network. Tomorrow, I'll ask them to fix it) and it works well. I found one problem on fontconfig's part. fontconfig's family name matching is case-insensitive for ASCII range, but it seems like it's case-sensitive for characters like 'MS' in 'MS ゴシック' (note that they're drawn from 'Fullwidth ASCII variants' at U+FF00 block). We lowercases family names to avoid problems with 'Sans vs sans vs SANS'. Keith, what do you use for family name comparison in fontconfig?
Assignee | ||
Comment 9•20 years ago
|
||
Comment 10•20 years ago
|
||
I'm using a custom string comparison function which ignores case only in the ASCII range. I know this is wrong. I can't use the libc string functions as I can't set the locale. Should I import a Unicode case table so I can do a full Unicode case insensitive match? Is there an easy place to get such a table?
Assignee | ||
Comment 11•20 years ago
|
||
http://www.unicode.org/Public/UNIDATA/CaseFolding.txt is what you want. However, given that the vast majority of fonts only have English names and only Japanese fonts have full-width ASCII variants in their names (Korean and Chinese fonts just use Korean script and Chinese characters), wouldn't it be an overkill for fontconfig? Well, I guess you can come up with a very compact data structure for that :-) ... Although it's not perfect, you may (at least for now) case-folds just ASCII range AND full-width ASCII-variant range. On Mozilla's side, I can just lowercase 'ASCII' range for now to work around it.
Assignee | ||
Comment 12•20 years ago
|
||
Attachment #169724 -
Flags: superreview?(blizzard)
Attachment #169724 -
Flags: review?(blizzard)
Assignee | ||
Comment 13•20 years ago
|
||
NS_IsASCIIFontName is not necessary any more so that I got rid of it.
Attachment #169724 -
Attachment is obsolete: true
Attachment #170444 -
Flags: superreview?(bryner)
Attachment #170444 -
Flags: review?(blizzard)
Assignee | ||
Updated•20 years ago
|
Attachment #169724 -
Flags: superreview?(blizzard)
Attachment #169724 -
Flags: review?(blizzard)
Updated•20 years ago
|
Attachment #170444 -
Flags: review?(blizzard) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #170444 -
Flags: superreview?(bryner) → superreview?(rbs)
Comment 14•20 years ago
|
||
Comment on attachment 170444 [details] [diff] [review] patch updated sr=rbs
Attachment #170444 -
Flags: superreview?(rbs) → superreview+
Comment 15•20 years ago
|
||
I didn't see an explicit comment, so I wanted to make sure this patch takes into account that fontconfig now has full Unicode case folding support.
Assignee | ||
Comment 16•20 years ago
|
||
Either way, this patch should work as it is now (in most of cases, if not all) I may move up 'ToLowercase' so that it's applied to the whole range of Unicode characters (instead of just [A-Z]) and get rid of the comment about fontconfig. On the other hand, if fontconfig does the full case-folding, we may as well be just lazy here (in which case I have to reword the comment to that effect) assuming that Japanese web authors always use the same case when specifying font names in 'wide' ASCII variant. That will save us a string copy and a full-fledged case folding....
Comment 17•20 years ago
|
||
Yes, fontconfig has complete Unicode case folding. I didn't apply the Turkic rules for İ/I/ı/i, but I'm thinking I should just fold all of those to i and be done with it. It seems rather unlikely to me that a font name would differ only in the dottedness of an i in a non-Turkic language. I managed to compress the case folding data into a 2213 bytes, which should be shared across all fontconfig applications as I was careful to not have any relocations in the data.
Assignee | ||
Comment 18•20 years ago
|
||
Comment on attachment 170444 [details] [diff] [review] patch updated asking for a1.8 Thanks for the comment and reviews. When checking this in, I'll rephrase the comment about fontconfig keeping the code as it is now.
Attachment #170444 -
Flags: approval1.8a6?
Comment 19•20 years ago
|
||
jshin, we're down to the very end of alpha6 and can't afford any regressions that would delay it longer. what kind of risk does this patch pose and what kind of testing has been done on it.
Assignee | ||
Comment 20•20 years ago
|
||
I tested the patch [1] with an old fontconfig and with a new fontconfig and found that it works as expected. In the first case, native font names are effectively skipped because the old fontconfig doesn't support non-ASCII font names. [1] I used http://jshin.net/moztest/cjkfont.html for testing and https://bugzilla.mozilla.org/attachment.cgi?id=139409 Only CJK Linux users visiting sites with CJK native fonts specified in CSS would be affected. Risk: low (with an old fontconfig, it tries next font if the first one has a non-ASCII name)
Comment 21•20 years ago
|
||
Comment on attachment 170444 [details] [diff] [review] patch updated a=asa for checkin to 1.8a6. thanks for the quick reply, jshin.
Attachment #170444 -
Flags: approval1.8a6? → approval1.8a6+
Assignee | ||
Comment 22•19 years ago
|
||
landed before 1.8a6 shipped. marking as fixed. thanks all.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 23•19 years ago
|
||
*** Bug 299382 has been marked as a duplicate of this bug. ***
Comment 24•19 years ago
|
||
*** Bug 312812 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•