Closed Bug 2514 Opened 26 years ago Closed 25 years ago

Unix: FONT FACE is not working for non-Latin-1 pages

Categories

(Core :: Internationalization, defect, P1)

Other
AIX
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: erik)

Details

This is a dup of bugsplat's 105023, moved over to bugzilla for 5.0 tracking. ----------------------------------------------------------- More IBM L10N bug documentation: IBM (Mary Hoetzel, heide@austin.ibm.com, phone 512 838 9604) reported the following defect. -------------------------------------------------- "NetHelp font specification not possible for Korea, Japanese, and maybe other non-iso-1 languages Jussi-Pekka Manterre at Netscape knows the details and is working on this." ------- Additional Comments From jpm 02/05/98 03:36 ------- This is related to an issue where it seems to be impossible to set fonts for elements using JavaScript Style Sheets under the X Window client. For example, changing: classes.label.all.fontFamily = 'arial'; to classes.label.all.fontFamily = '-adobe-helvetica-medium-r-*--*-*-*-*-p-*-iso8859-1'; has no effect. I've asked this on the X-Heads newsgroup (news:34A894E7.7700221E@netscape.com) and Chris McAfee replied that Joe Ruff was Mr. Stylesheets. Joe? ------- Additional Comments From joeruff 02/05/98 06:46 ------- not anymore ------- Additional Comments From dp 02/05/98 10:52 ------- mmh! I thought fonts were to be specified on the web just by their name. So the font specification here would be classes.label.all.fontFamily = "Helvetica" Having said that, I should point that if <FONT FACE='-adobe-helvetica-medium-r-*--*-*-*-*-p-*-iso8859-1'> This is font '-adobe-helvetica-medium-r-*--*-*-*-*-p-*-iso8859-1' </FONT> works, then the classes.label.all.fontFamily should also work. ------- Additional Comments From jpm 02/05/98 17:56 ------- <FONT FACE='-adobe-helvetica-medium- ...> didn't work either. So, the problem is: how to make an X Window font "known" to the layout engine so that it can be used in FACE="..." instead of Helvetica, Times etc. Looking at the XFE code it seems as if Helvetica, Times, Courier & Symbol are specifically named and mapped to their X Window font equivalents. Is there some other (working) syntax for using X font names in FACE="..."? ------- Additional Comments From doreen 02/23/98 18:57 ------- Does anyone have any ideas about how to specify the NetHelp Fonts for Korean and Japanese? Not being able to specify the fonts is preventing IBM from completing their localizations for Japanese and Korean. They need a response immediately since they need to complete these localizations this week. ------- Additional Comments From dp 07/07/98 22:14 ------- Move david william's bugs to harishd. He should be starting 7/13/1998 ------- Additional Comments From mldavis 08/26/98 15:31 ------- Harish, I asked Mary Hoetzel of IBM for an update on this bug, here's what she sent to me today: ----------------------------------- Subject: Re: Question on Old Bug Date: Wed, 26 Aug 1998 17:19:16 -0500 From: Mary Hoetzel <heide@austin.ibm.com> To: mldavis@netscape.com CC: Linda Lindsay <llindsay@austin.ibm.com> References: 1 Hi Mike, Things are going pretty nice. We're wrapping up Navigator 4.06 to be shipped in October. Yes, this bug is still outstanding and, of course, we would like to have a fix for it. The problem are the font family specifications for nethelp in nethelp/netscape/shared/NetHelp1.css (for the Contents pages) and various files (CntTool.js, IdxData.js, IdxFill.htm, IdxKey.htm, IdxTopic.htm, ToolUI.htm) in the nethelp directory (for TOC, Index, etc.). The original specifications are arial, helvetica, and sans-serif. They work only with iso-1 fonts. But they don't work for iso-2, iso-5, or the double-byte languages. I'm not sure about sans-serif, but anyway, this is a very generic font specification, and we would like to specify the fonts more precise. I tried some specifications for double-byte languages. For example, because the font family helvetica is the 2nd field in the XLFD, I used the corresponding 2nd field "kai" for the Chinese double-byte font -ibm_aix-kai-medium-r-normal--24-172-100-100-c-240-gb2312.1980-0. But this didn't work. The result is, that whatever is specified in Font Preferences for the non-iso-1 languages, is used in nethelp. That means, nethelp appearance changes. For iso-1, the font family specifications in the above mentioned files make the nethelp appearance independent from the settings in Font Preferences. BTW, specifications for font sizes in those files are recognized for the non-iso-1 languages. Finally, this is not a nethelp specific problem, but the general problem, how to specify font families for non-iso-1 languages as inline (I haven't tested with the <FONT> tag yet), document-level, or external style sheets. Mary --------------------------------------- So it's still a bug for IBM. You can work with Mary directly (heide@austin.ibm.com, phone 512 838 9604) for more info. Thanks, ~ Mike Davis ------- Additional Comments From harishd 09/09/98 17:08 ------- Changing TFV to 5.0 ------- Additional Comments From harishd 09/15/98 18:27 ------- This bug doesn't look like a critical bug. Changing priority to P1. Assigning the bug to ftang. Frank....could you take a look at this bug. Thanx:) ------- Additional Comments From ftang 09/17/98 16:56 ------- Erik: Could you take a look at this one. It seems the font face does not work on UNIX for non-Latin pages. ------- Additional Comments From ftang 09/18/98 09:37 ------- erik, can you handle this ? ------- Additional Comments From pollmann 09/22/98 17:04 ------- *** Bug 309040 has been marked as a duplicate of this bug. *** ------- Additional Comments From pollmann 09/22/98 17:08 ------- I just marked 309040 as a dup of this bug, even though it is a Mac bug, we are having the exactly the same problems. For a test page, pull up 4.5 on a Mac and check out: http://twain/client/stylestest-utf8.html Another page I cooked up is at: http://blueviper/css/noniso8859fonts/utf8.html (oddly enough, this page seems to work on X... ???)
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
What is fontFamily ??? fontFamily is defined in CSS 1 and CSS 2. So please take a look at CSS 1- http://www.w3.org/TR/REC-CSS1 and CSS 2- http://www.w3.org/TR/REC-CSS2/ first In 5.2.2 'font-family' section of CSS 1 "5.2.2 'font-family' Value: [[<family-name> | <generic-family>],]* [<family-name> | <generic-family>] Initial: UA specific Applies to: all elements Inherited: yes Percentage values: N/A The value is a prioritized list of font family names and/or generic family names. Unlike most other CSS1 properties, values are separated by a comma to indicate that they are alternatives: BODY { font-family: gill, helvetica, sans-serif } There are two types of list values: <family-name> The name of a font family of choice. In the last example, "gill" and "helvetica" are font families. <generic-family> In the example above, the last value is a generic family name. The following generic families are defined: 'serif' (e.g. Times) 'sans-serif' (e.g. Helvetica) 'cursive' (e.g. Zapf-Chancery) 'fantasy' (e.g. Western) 'monospace' (e.g. Courier) Style sheet designers are encouraged to offer a generic font family as a last alternative. Font names containing whitespace should be quoted: BODY { font-family: "new century schoolbook", serif } <BODY STYLE="font-family: 'My own font', fantasy"> If quoting is omitted, any whitespace characters before and after the font name are ignored and any sequence of whitespace characters inside the font name is converted to a single space. " Therefore, '-adobe-helvetica-medium-r-*--*-*-*-*-p-*-iso8859-1' should not be used as font-family name, this is a XLFD, not a fontFamily- now let's read "Volume One Xlib Programming Manual for version 11" by Adrian Nye, O'Reilly & Associates, Inc. Section A.1.1 Font Naming Conventions- It clearly specify the 2nd field in the XLFD is "font family", therefore, only "helvetica" in '-adobe-helvetica-medium-r-*--*-*-*-*-p-*-iso8859-1' is font family. This bug exist in the 4.x code base because whoever working on font face in the 4.0 UNIX development team 2 years ago simply only apply face for ISO-8859-1 page. I doubt the same thing will happen in the Gecko code at all.
I18n component in Bugzilla being retired. Moving these bugs to Internationalization component.
QA Contact: 3851
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Summary: FONT FACE is not working on UNIX for non-Latin 1 pages → UNIX GFX Unicode Text Drawing- FONT FACE is not working on UNIX for non-Latin 1 pages
Target Milestone: M4 → M5
Summary: UNIX GFX Unicode Text Drawing- FONT FACE is not working on UNIX for non-Latin 1 pages → Unix: FONT FACE is not working for non-Latin-1 pages
Target Milestone: M5 → M6
Target Milestone: M6 → M7
Target Milestone: M7 → M10
Target Milestone: M10 → M12
Target Milestone: M12 → M15
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16
This was fixed a while ago in Mozilla. Marking FIXED. If QA discovers problems, please log separate, specific bug reports, since this one is very long and very old.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M16 → M14
I verified this in 2000041413 Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.