non-ASCII font family names in CSS are not recognized

RESOLVED FIXED

Status

()

Core
Layout: Text
--
major
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: Arthur Tsai, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla1.4a

Mozilla Don't Recognize Chinese Name Font Family in CSS file

Reproducible: Always

Steps to Reproduce:
1.Make a page which contains Chinese in Big5 encoding.
2.Make a CSS file which has:"body{font: ¥é§ºÅé/*this depends on the Chinese Name
Font Family you have*/}" 
3.Link the page to the CSS. Open the page.

Actual Results:  
The font does not change to the font you selected.

Expected Results:  
The font changes.

Comment 1

15 years ago
*** Bug 203746 has been marked as a duplicate of this bug. ***
Is the CSS stylesheet being sent with the right character set?
This bug needs a testcase.
INVALID due to lack of testcase - we can't do anything here without one.
marking INVALID, but please do reopen this bug when you have a .html file
showing this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 5

14 years ago
Reopening... looking at the code it seems we assume that CSS font names only
contain chars within the ASCII range... anything beyond that causes havoc.

jshin:
Can you provide a testcase (korean, chinese, etc.), please ?
OS: Windows XP → All
Hardware: PC → All

Updated

14 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Would you mind mentioning which code?

Comment 7

14 years ago
There are numerous pages in CJK  that list font families only in native scripts.
I haven't taken a look at what CSS code does, but even if it transparently
passes through non-ASCII family names (Roland, please, point us where it does
not if it does not), most ports of gfx can't handle them at the moment. 

 1. For the obvious reason, Gfx:X11core fonts can't. XLFD doesn't allow anything
beyond ASCII.
 2. Gfx:Xft can't because of the limitation in fontconfig (see bug 223653)
 3. Gfx:Win can't on non-CJK versions of Win 9x/ME / Win 2k/XP with non-CJK
locales because of the limitation in Win32 font APIs. How does MS IE can handle
it? Well, it can't either. Then, why do people use CJK font names in their web
pages? Because they have a very flawed notion of  the web and have so little
idea of importance of the platform independence and interoperability that they
don't care if their web sites work fine on CJK versions of Windows 9x/ME and
Windows 2k/XP (that is, they don't even check whether their web pages work fine
on English Windows). See bug 227815.
  4. I have yet to take a look at Gfx:Mac and other ports. 

Comment 8

14 years ago
Reporter, we want to fix this bug, but there are things we can't do due to the
limitation of platform APIs (see, especially, bug 227815) The  way to list CJK
fonts is to list both native names (CJK names) and English names like this (set
the encoding to UTF-8):

font-family: MingLiU, 細明體

As for testcase, the reporter already provided one (effectively) except that he
used Big5 in comment #0. 

So in other words this needs to be split up into bugs filed on each GFX impl? 
Layout just treats the font family names as UTF-16 strings as far as I know;
they are passed to GFX as such, last I checked.

Comment 10

14 years ago
I'm now pretty sure that layout does the right thing as bz wrote. Otherwise, bug
227815 wouldn't have been filed. 

As for fixing gfx, bz is right that we have to take it one by one. We already
have bug 223653 for Xft(that depends on fontconfig
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=171 )

As for Win32 (bug 227815 comment #2), it's Win32 APIs that is to blame. We can
work around by poking 'deep' into truetype fonts (the same can be done with Xft
port if fontconfig is not fixed soon), but that might be a substantial work. In
the meantime, Win2k/XP users can set the system loacle to that corresponding to
their native scripts (in case of the bug reporter, setting the default system
locale of his English Win2k/XP to zh-TW would solve the problem for Taiwanese
fonts). 

BTW, bz and dbaron, what do you think of adding a couple of lines to CSS 2.1 (if
it's not too late) that read

  Font family names in non-ASCII are not recognized by most user agents so that
it is always a good idea to list the corresponding ASCII family names as well.

Well, this may not belong there. (I'm planning to submit an FAQ item on this
issue and other issues related with the font specification to W3 I18N WG.)

Comment 11

14 years ago
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4rw4.asp

Hope I am understanding the prose properly, it seems that one can get the
English name by passing the CJK name to EnumFontFamiliesEx, then use that to
create the font. Is that your reading too?

Updated

14 years ago
Depends on: 231426

Comment 12

14 years ago
I filed bug 231426 for Gfx:Win32 as you noticed (add yourself to CC if
interested) and am making this depend on bug 223653 for Gfx:Gtk-Xft.
Status: UNCONFIRMED → NEW
Depends on: 223653
No longer depends on: 231426
Ever confirmed: true

Comment 13

14 years ago
Created attachment 139409 [details]
test case

This has test cases for SC, TC, J and K. Fonts specified are those available on
typical Windows and Linux distributions. As for Mac OS X fonts, I'm still
waiting for a reply from Apple (I asked them for the list of system default
fonts on Mac OS X last month.)

Updated

14 years ago
Summary: Moz Don't Recognize Chinese Name Font Family in CSS → non-ASCII font family names in CSS are not recognized
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text

Comment 14

5 years ago
This has been resolved, we correctly handle localized family name matching on all platforms.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.