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: