[Xft] support localized font family name

RESOLVED FIXED

Status

defect
RESOLVED FIXED
16 years ago
11 years ago

People

(Reporter: jshin1987, Assigned: jshin1987)

Tracking

({intl})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Assignee

Description

16 years ago
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

16 years ago
fontconfig  bug I've just filed :
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=171
Assignee

Updated

16 years ago
Blocks: 203745

Comment 3

15 years ago
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

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

Comment 5

15 years ago
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

15 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

15 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

15 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

15 years ago
Posted file test case

Comment 10

15 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

15 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

15 years ago
Posted patch patch (obsolete) — Splinter Review
Attachment #169724 - Flags: superreview?(blizzard)
Attachment #169724 - Flags: review?(blizzard)
Assignee

Comment 13

15 years ago
Posted patch patch updatedSplinter Review
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

15 years ago
Attachment #169724 - Flags: superreview?(blizzard)
Attachment #169724 - Flags: review?(blizzard)
Attachment #170444 - Flags: review?(blizzard) → review+
Assignee

Updated

15 years ago
Attachment #170444 - Flags: superreview?(bryner) → superreview?(rbs)

Comment 14

15 years ago
Comment on attachment 170444 [details] [diff] [review]
patch updated

sr=rbs
Attachment #170444 - Flags: superreview?(rbs) → superreview+

Comment 15

15 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

15 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

15 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

15 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?
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

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

15 years ago
landed before 1.8a6 shipped. marking as fixed. thanks all.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
*** Bug 299382 has been marked as a duplicate of this bug. ***
*** Bug 312812 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.