Closed Bug 114705 Opened 23 years ago Closed 21 years ago

Arial bold italic font display incorrect in Dec4 builds onwards

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: motrei, Assigned: shanjian)

Details

(Keywords: fonts)

Attachments

(11 files)

xfs config attached
1.10 KB, text/plain
Details
Jpeg of bad display
4.82 KB, image/jpeg
Details
My preferences.js
6.71 KB, text/plain
Details
Jpeg of Bad arial output on 10 dec build
17.28 KB, image/jpeg
Details
Jpeg of good arial output on Dec 2 build
17.69 KB, image/jpeg
Details
Debug output with the suggested env var set
53.86 KB, text/plain
Details
An even smaller HTML snippet
89 bytes, text/html
Details
New debug log with Dec 10 build, NS_FONT_DEBUG=1D
63.15 KB, text/plain
Details
New xfs config with microsoft fonts added
1.03 KB, text/plain
Details
Font debug log with McMillin's HTML snippit, buildid 2002010208
45.19 KB, text/plain
Details
new debug log, NS_FONT_DEBUG=1D
6.09 KB, text/plain
Details
The following simple testcase displays correctly in build 2001120221 (Dec 2 build) but incorrectly in build 2001120408 (Dec 4 build) and later. I seem to remember it displaying incorrectly in the Dec 3 builds, but I am reluctant to try them given the preferences corruption: <html> <head> <title> Trial page </title> </head> <!-- Commenting out the next line fixes the problem --> <font face="Arial"> <p> <b><i> This is supposed to be bold italic </i></b> <p> </body> </html> Note that I did try one of the mozilla versions that had preference corruption, but I deleted my .mozilla directory and restarted from scratch, so that shouldnt be the cause of this. In any case, I'm trying the Dec 2 build right now and it is displaying correctly. When incorrect, the letters seem to have extra whitespace between them and are neither bold nor italic. They also seem bigger than normal. I am running Redhat Linux 7.2 with XFree86 4.1 on an Nvidia GeForce2MX 32MB card; font display uses xfs. I'll try to attach my xfs config file. The system is running on an Athlon 700. I am using Nvidia 1.0-2313 drivers. Here is the font path: catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/100dpi:unscaled, /usr/X11R6/lib/X11/fonts/misc, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/X11R6/lib/X11/fonts/cyrillic, /usr/X11R6/lib/X11/fonts/CID, /usr/X11R6/lib/X11/fonts/local, /usr/X11R6/lib/X11/fonts/latin2/Type1, /usr/share/fonts/default/TrueType, /usr/share/fonts/default/Type1, /usr/share/AbiSuite/fonts, /usr/share/fonts/ja/TrueType # in 12 points, decipoints default-point-size = 120 # 100 x 100 and 75 x 75 default-resolutions = 75,75,100,100 # use lazy loading on 16 bit (usually Asian) fonts deferglyphs = 16 # how to log errors use-syslog = on
Summary: Arial font display incorrect in Dec4 builds onwards → Arial bold italic font display incorrect in Dec4 builds onwards
Attached file xfs config attached —
->Layout
Keywords: fonts
worksforme, linux build 2001-12-10-08 Font stuff is intl.
Assignee: asa → yokoyama
Component: Browser-General → Internationalization
QA Contact: doronr → teruko
Attached image Jpeg of bad display —
Attached file My preferences.js —
Note that the window manager I use is icewm 1.09. I still see the bug with the Dec 11 build. Does anyone using RedHat 7.2 not see this bug? If so, could you send me your preferences and fontpath?
This bug is still ocurring in buildid 2001121708. Has anyone tried to reproduce it? I gave a simple enough testcase; I see this behavior on several real pages. What more should I do to have someone at least check to see if it exists for them or not (and if not, to attach their preferences here so that I can fix the problem for me)? Surely displaying bold italic in arial is a common enough operation since several web pages use this font. I believe I've done what is reasonable: created a small testcase, attached graphical descriptions of good and bad behavior and isolated to within a few days the good and bad builds. What more should I do to get someone to look at this?
Setting status to NEW in the hoped that an engineer will look.
Status: UNCONFIRMED → NEW
Ever confirmed: true
layout bidi issue-> smontagu
Assignee: yokoyama → smontagu
this is probably an effect of bug 94327 motre: would you: Kindly attach the html to this bug Kindly: set the environment variable NS_FONT_DEBUG to 1D do a minimal run (eg: ./mozilla http://your_web_server/your_page) attach the output to this bug
The testcase is inline in my first comments on this bug. I reproduced this on a different machine also running RedHat 7.2 with XFree86 4.1 and the same Nvidia drivers. This machine was freshly installed and has no gnome UI or KDE on it. I will attach the font log immediately after this comment. Regarding the bug that was referenced in the comment above (and marked as fixed): are the fixes available in any nightly I would have access to? It wasnt clear from the bug, and I still saw this bug on bits built Dec 17.
I invoked as suggested ( NS_FONT_LOG=1D mozilla file:///path to file ). Note that I was using classic skin on this invoke (which is a Dec 14 nightly 2001121408) but have seen the bug on later nightlies with modern skin as well.
Also seeing this in the 0.9.7 (2001122617) build. It's apparently even simpler than the bug title suggests -- this is actually just caused by adding the <i> tag.
I added Microsoft fonts to my fontpath and removed a directory that was providing alternate arial fonts. This fixed my testcase, but did not fix the smaller testcase created by Rob McMillin . I tried this both on the Dec 10 build as well as buildid 2002010208 . I will attach the revised debug output (for my working testcase) as well as my modified xfs config file.
Note that even after adding Microsoft Arial fonts, I still see the problem with Rob's little snippit of HTML. Here's the attached debug log. Any chance someone from Mozilla would respond confirming this bug or denying its existence?
should this be assigned to shanjian?
this occurred to me when upgrading from moz 9.5 to 9.7 (i'm on red hat 7.1) x fonts are affected as descibed - imported truetype fonts (eg verdana) do not seem (for me) to be affected
this bug should be looked at per ftang -> Shanjian Shanjian: this would be a good opportunity for us to discuss some of the details of how the moz X font system works
Assignee: smontagu → shanjian
Target Milestone: --- → mozilla0.9.9
The problem is in font "-alias-helvetica-medium-i-normal--16-*-0-0-c-*-iso8859-1". This font is not italic even if it says itself it is. Also in the test case, "arial" is mistyped as "ariel", and that's why you can't see correct display even after "arial" font is added.
Status: NEW → ASSIGNED
Another factor that contributes to the problem is oblique and italic. Some adobe helvetica font are marked as oblique, and because of that, those fonts have lower precedence. It looks like in unix word, oblique has the same meaning as italic.
Possible solutions: 1. Ban all or some -alias-helvetica-* fonts. 2. Treate "o" and "i" equally Brian, what do you think?
Font banning would be a good idea but at present it does not work. It was disabled because it had a performance penalty. See bug 117877. Italic means emphasize by slanting. Oblique means programmatically slanted which is certianly similar but italic tends to look better since it was built slanted instead of mechanically slanted. Italic should have precedence over oblique. Besides, changing the precedence of oblique and italic would be a global change to fix a specific problem and could well cause other unwanted side effects.
brian, I am not sure the difference of oblique and italic is true in X font world, especially if a bitmap font says itself is oblique. Clearly a oblique bitmap font is not generated programmatically in applications. I searched those key words in web, and several documents suggesting that italic applied to "Times" and oblique applies to "helvetica" and "Courier". This might not be true now and in future after scalable font types (type1, ttf, etc.) are introduced to X world. But it should remains reasonably constant for bitmap fonts. So to treat 'i' and 'o' equally for bitmap fonts might be a feasible option. Otherwise traditional "helvetica" and "courier" bitmap font will be less likely to be selected as more scalable fonts introduced.
I'd be very careful about making a global change to fix a specific problem. This tends to lead to follow on problems.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020129 I upgraded to XFree86-4.1.0-15 (and associated fonts) a few days ago, and noticed that this bug is no longer a problem. I tried builds back to a week ago (1-23-02) and the bug doesn't show up with those builds too.
hum... does this mean we should consider closing this bug?
That is because of the availability of additional fonts. Considering the fact that helvetica is such a popular fonts in X and -adobe-helvetica-* is almost available in every system, resorting to (ugly) scalable font just for italic helvetica does not make much sense. I will be cautious about the possible side-effect and will test it in my local tree thoroughly before I submit the patch. Since there is nobody crying for it, there will be no hurry.
I downgraded my XFree86 back to the standard Redhat 7.2 (4.1.0-3), and I still couldn't reproduce the bug. I haven't upgraded much else recently. I tried going back as far as 1-14-02 build, and they all work fine. But I'm almost positive that this was still an issue at that point. I also tried 0.9.7, and it works ok too.
new debug log. the main difference between this and attachment #63335 [details] is that I am getting "abisource-arial" instead of "monotype-arial".
FWIW, my system started life as a RH 6.1 install and has suffered through successive upgrades, which probably explains the difference. I'm doing the upgrade to the latest XFree86 code.
Ah, works very goodly now. So the real problem is people who can't tell the difference between a mermaid and a font.
I was finally able to reproduce this again by directing XFree86 to use a remote xfs running 4.0.3.
> I will be cautious about the possible side-effect and will test it in my > local tree thoroughly before I submit the patch. Let me caution that testing in a local tree will generally *not* find the problems that are likely to happen in the field. Making a global font change to fix a specific font problem is often a path fraught with problems.
reset TM.
Target Milestone: mozilla0.9.9 → Future
For what it's worth, I ran into something very much like this and it's actually a RedHat bug. 7.2 ships with some bad Japanese fonts (why this affects Latin1 pages is beyond me, but I'm no font guru). Downloading the new fonts from RedHat fixed this problem for me. RedHat's support site mentions this, but only if you bother to look very deeply at the Japanese font update (which I imagine most RedHat users will not since they won't be seeing this problem on Japanese pages). You may want to make a relnote issue out of it because A) Redhat 7.2 will be popular and B) The fix at RedHat is non-intuitive and people may blame Mozilla because it's more logical (no offense).
I think it's fair to say this is a RedHat bug, but in general, the browser might make concessions to people's inability to spell :-) (Ariel vs. Arial).
the ariel vs arial thing was just a typo in the testcase, and not really related to this bug. with "ariel", Mozilla fell back to Helvetica, which (IIRC) exhibitted the same behavior.
Appropriate comment added to bug 126776 (0.9.9 release notes bug)
Not be be a nitpicker, but... The RedHat problem is with Helvetica aliasing, not Arial. This bug was caused by Arial being misspelled, and Moz falling back to Helvetica, which was the buggy one. Release notes may be important enough to nitpick over stuff like that.
Keith, please comment in bug 126776 with the fixed wording.
boris and keith: the Japanese / Korean font issues are not related to this bug. I saw this bug with RedHat 7.1 as well as 7.2. This bug went away without me upgrading ttfonts-ja on either machine. The real issue seemed to be in the XFree86 distribution (probably xfs).
This may be a case of two similar (maybe the same) problems with multiple solutions that apply to both. I simply don't know enough about UNIX font handling to swear to it. What I do know is that a fresh vanilla RedHat 7.2 install with Moz updated to 0.9.8 exhibits the behavior described (widely spaced letters when italic/bold Helvetica is requested), and installing the Japanese font update fixes it. Updating xfs or Xfree may well solve the same problem in different ways (e.g. what is "aliasing" and could different versions of xfs handle it differently when using the same fonts? I dunno either...), but this way we have a RedHat document to point users to and get them out of our hair.
Keith: you were right! my xfs config file got screwed up during my XFree86 upgrade and pointed to the wrong location for the ja fonts. Correcting it brought back this problem. here are some other relevant details 1) there is no Arial bitmap font, so Mozilla falls back to Helvetica (even when Arial is spelled corectly). 2) the ttfonts does not actually override the Helvetica (unless it is listed first in the fs config file). The problem is that adobe's Helvetica has no italic typeface (only oblique), so Mozilla keeps searching and grabs the ttfonts-ja's Helvetica because it has a real italic.
Abiword has a similar bug with fonts: they fake an "arial" font that is an alias for an ugly bitmap font instead. There are at least a dozen bugs on in in both the redhat and the abisuite bugzillas. Could that be the issue here?
Works For Me on 1.0. But maybe I'm not understanding the problem.
WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040202 Reopen if your opinion is different and you can reproduce this with a current build.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: