Failing to calculate width of TrueType fonts on XFree 4.0

VERIFIED FIXED in mozilla0.9.7



18 years ago
17 years ago


(Reporter: ilya.konstantinov+future, Assigned: jbetak)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+] looks like a dup)


(7 attachments)



18 years ago
Using TrueType fonts Monotype's Times New Roman for Serif, Monotype's Arial for
Sans-Serif and Monotype's Courier New for Monospace.

Using XFree 4.0 with the FreeType module.

Specifying those fonts in the Preferences works fine and pages are rendered well
using the TrueType fonts. The problem occurs once a page tries to specify it's
own fonts (with a <font face=...> tag or with CSS font-family:). If the font it
specifies happens to be a TrueType one (or maybe just scalable?), even if it's
the same font as currently in the Preferences, the page renders incorrectly.
When specifying a font which is a bitmap font (e.g. Helvetica on my system), the
page renders correctly with the font as specified.

By rendering incorrectly, I mean:
For some reason Mozilla fails to calculate the width of the font, thinking it's
actually shorter than the text which actually gets outputted to the screen, so
if I have code such as:

One two three four five <a href="#">site</a>

the link word "site", which is separated from the text's flow (due to being a
link, differently formatted or whatever), is placed somewhere on top of "four".
It seems as if Mozilla thinks that the text should've already ended at that point.

We could've claimed it's an XFree 4 TrueType engine problem, but it actually
displayed fine while specified in the Preferences. Setting "Always use my font
settings" in the Preferences can serve as a temporary solution.

Comment 1

18 years ago
Created attachment 19139 [details]
Demonstration on the problem as seen on
*** Bug 59873 has been marked as a duplicate of this bug. ***

Comment 3

18 years ago
The bug apparently doesn't reproduce when using the 'xtt' TrueType module
instead of 'freetype' in XFree 4.0, but then again, 'xtt' causes real weird font
problems when iso-10646-1 (Unicode) encoding variants of fonts are available in
the fonts.dir.

Comment 4

18 years ago
This bug can only be reproduced when the fonts.dir has iso-10646-1 (Unicode)
versions of the fonts. (Those are the Microsoft Web Core fonts which *do* offer
Unicode versions) Without the iso-10646-1 encoded entries, it all layouts fine.
Add them to fonts.dir, 'xset fp rehash', reload Mozilla - and it's broken!

BTW; the XFree86 'xtt' module, while working even worser (Segfaulting often)
shows even scarier problems in Mozilla (only Mozilla!) with iso-10646-1 fonts

Comment 5

18 years ago
Reporter is this still a problem with the latest nightlies?

Comment 6

18 years ago
Yes, using build 2000121921. Still the same problem exhibited on Google and 
the browser's interface. The bug report I've given is fully detailed and 
allows you to perfectly to reproduce the problem.

Comment 7

18 years ago
Marking NEW as per comments.
Ever confirmed: true

Comment 8

18 years ago
Strange. I didn't get this using SuSE's XFree86 4.0 and 4.0.2 but I get this
after the update to 4.0.3 - perhaps the previous didn't output unicode to fonts.dir

Anyway, this makes sites like Mozillazine very hard, sometimes impossible to
read, and is seen by lots of people (it also makes us looking much worse than
konqueror in "Embedding external parts into KDE" - I can't even look at some file names at LXR, the links in a forth row of the file list are displayed
completely above other links at the right column of the page!

As this is very annoying nominating for 0.9.1 and nscatfood.
Keywords: mozilla0.9.1, nsCatFood

Comment 9

18 years ago
I can't believe that's marked a bookmarks bug!

Moving to Layout - might not be right, but surely better than bookmarks...
Component: Bookmarks → Layout

Comment 10

18 years ago
hmm, interstesting.
I'm seeing this at which uses lots of <font
face="Verdana, Arial, Helvetica, sans-serif"> tags - but I'm not seeing this on
my own pages ( which use css "font-family: Arial,
Helvetica;" (from an external css file).
I'll have to look if I'm seeing this on Verdana but not Arial, or if <font> vs.
css is the issue here...

Comment 11

18 years ago
seems this is a Verdana vs. Arial issue for me - perhpas Verdana is using
Unicode and Arial doesn't?
layout => karnaze. 
Assignee: ben → karnaze

Comment 13

18 years ago
*** Bug 78253 has been marked as a duplicate of this bug. ***
*** Bug 76625 has been marked as a duplicate of this bug. ***

Comment 15

18 years ago
Going on Ilya's comment about 10646 fonts I decided to see what happened when I
played with fonts.dir a little bit and I came up with a very good workaround.

Go into the directory with your TrueType fonts and do the following:

# mv fonts.dir fonts.dir.10646
# sed 's/^.*iso10646.*/#&/' < fonts.dir.10646 > fonts.dir

This comments out all the iso10646 encodings of the font without losing the
whole font.  Then restart X and xfs.  After doing this I haven't seen a single
font rendering problem on any of the sites I was seeing it before.

Comment 16

18 years ago
I hope it won't be the final "solution" to this bug, since some of us actually
need those iso10646-1 font entries.
*** Bug 78693 has been marked as a duplicate of this bug. ***

Comment 18

18 years ago
I tried to use your suggested workaround and wound up having
XFree86 crashing on me all the time, so, at least for Xservers
built from CVS, this workaround isn't an option.
*** Bug 78469 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
Re: Cory Dodt 2001-04-30 23:59

The workaround that you suggested didn't seem to make any difference on my box.
 Rather, it made XFree86 (4.0.x) a bit unstable.  It hung on startup, and then
dumped.  I had to reinstall Xfree to get it to work again.

Don't think that's a worthwhile work-around.  I wouldn't recommend it to everyone.

My system:
AMD Athalon 750 Mhz, Linux Mandrake 8.0, Xfree86 4.0.x, Mozilla 2001050315
*** Bug 79625 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
Reassigning to ftang.
Assignee: karnaze → ftang

Comment 23

18 years ago
reassign to bstell. cc
mark it as moz0.9.2
Assignee: ftang → bstell
Target Milestone: --- → mozilla0.9.2

Comment 24

18 years ago
frank, do you know who sohuld be the QA for this bug b/c it sure isn't me?
QA Contact: claudius → ftang

Comment 25

18 years ago
Is this a dup of 78643 ? Can some one try the Comments From 2001-06-
09 11:00 in bug 78643 ?

Comment 26

18 years ago
Yes, definitely a dup. Unmarking "Allow documents to use their own fonts" 
solves 78643 too.

Note my comment -- the problem only preproduces when the page somehow manages 
to specify fonts on it's own, even if those are the same as the fonts in 
Preferences. Thus, we can't even say the fonts metrics are messed up, since 
Mozilla CAN render those fonts correctly.

Comment 27

18 years ago
pdt+ base on 6/11 pdt meeting.


18 years ago
Whiteboard: [PDT+]
*** Bug 86470 has been marked as a duplicate of this bug. ***


18 years ago
Whiteboard: [PDT+] → [PDT+]no progress yet.

Comment 29

18 years ago
is someone sure that when the page use the preference specified font 
we actually use the ttf unicode font and not a bitmap font?

Could someone:
 1) make a -very- simple page that demonstartes the problem add attach
    it to this bug
 2) "setenv NS_FONT_DEBUG 5", display the page, and attach the results
    to this page
 3) attach a "xlsfonts -u" output to this bug

would you kindly attach the data rather than insert it so this page does
not grow really long.


Comment 30

18 years ago
Created attachment 39215 [details]
A very simple testcase.

Comment 31

18 years ago
Created attachment 39217 [details]
Log of font requests while loading the testcase (NS_FONT_DEBUG=5)

Comment 32

18 years ago
Created attachment 39218 [details]
Log of font requests while loading the testcase (NS_FONT_DEBUG=5)

Comment 33

18 years ago
Created attachment 39219 [details]
xlsfonts -u dump on testcase system (XFree86 fonts, Microsoft Web Fonts and IBM JRE TrueType fonts) -- in the testcase, Microsoft's fonts were used

Comment 34

18 years ago

1. "Preferences font" doesn't matter, since the problem reproduces when the page
specifies it's OWN font (via <font face=...>, via CSS, doesn't matter).
2. Yes, the page does manage to specify it's OWN font (unless I prevent
documents from using their own font -- which is an workaround for the bug).
3. Yes, the font used looks on screen like the genuine Monotype foundry Arial font.

Comment 35

18 years ago
If it helps, i have seen exactly the same problem manifest itself on Opera 5 for
Linux, with coloured link text that overlaps the text surrounding the link.

This problem is present even after it has been resolved with regard to Mozilla.

The blame for this issue probably lies at least partially either with xfs or
Xfree86, but it is puzzling that Mozilla renders the fonts correctly *most* of
the time.

I have fixed all my font rendering problems in Mozilla by going through
fonts.dir and erasing the top 10 encoding lines for each of my truetype fonts.

This was an extremely non-empirical method, i just got rid of most of the
encodings present (the top 10 or so) and my Mozilla font rendering problems
disappeared (also you need to update the number of fonts on the top line of the

This indicates to me that Mozilla is inconsistently selecting font encodings, or
is being supplied with inconsistent encodings when it requests a font - why this
should affect the metrics of the font i have no idea.

Comment 36

18 years ago
jbetak- can you try to set up the test environment and reproduce this problem.
talk to . she seems install the font once.
Assignee: bstell → jbetak

Comment 37

18 years ago
my last comment:
>talk to . she seems install the font once.
Sorry. I am confused with another bug.

Comment 38

18 years ago
is this the same bug as bug 78643?

Comment 39

18 years ago
is this the same bug as bug 63831?

Comment 40

18 years ago
I looks like a dup of 78643 and 63831

Comment 41

18 years ago
If this is a dup, please mark it so.  Otherwise, please add eta to status
Whiteboard: [PDT+]no progress yet. → [PDT+] looks like a dup

Comment 42

18 years ago
mark it as dup of 78643

*** This bug has been marked as a duplicate of 78643 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 43

18 years ago
Created attachment 41518 [details]
html; A very simple testcase specifying a freetype-arial-10646-1 font

Comment 44

18 years ago
Created attachment 41519 [details]
slightly revised simple testcase specifying a freetype-arial-10646-1 font

Comment 45

18 years ago
would any developers who see this problem try this fix for bug 63831
and see if it also fixes this bug?


Comment 46

18 years ago
the fix for bug 63831 (now checked in) should fix this.


18 years ago
QA Contact: ftang → andreasb

Comment 47

18 years ago
Switching QA contact to ylong.  Yuying, can you verify that the fix for bug
63831 also fixes this problem? Thanks.
QA Contact: andreasb → ylong

Comment 48

18 years ago
Bug 63831 has been resolved.
I checked it by change the fonts setting to TTF following setting in description
of reproter, and I couldn't reproduce the problem on google site.
I'll mark it as verified.

Comment 49

17 years ago
I have been experiencing this problem for quite some time. I am currently using
Mozilla 0.9.5, but this bug has been around for as long as I can remember. Lines
go off the screen and are not wrapped correctly. Links are superimposed on
ordinary text, and font spacing is messed up when the font style (bold,
underline, etc.) is changed.

When using the MS truetype fonts (through Freetype) , the problem is absolutely
terrible. When using the standard Times and Helvetica things are better, but not
fully fixed.

I currently have Mandrake Linux 8.1 (with XFree86 4.1), but as I said before
this problem has been around for quite a while. I havn't had this problem in
other browsers (I've tried Opera, Netscape 4 and Konqueror), except for Galeon
(which is GTK-based and uses Gecko). I have also noted a similar problem in
GNOME's GDict Panel applet. This leads me to think that the problem is not with
Mozilla but rather with how it communicates with the X font server (or maybe
even with GTK, but I don't think Mozilla uses GTK for font-handling).
Resolution: DUPLICATE → ---

Comment 50

17 years ago

Would you kindly provide a simple test case?

Would you set the environment variable NS_FONT_DEBUG=D, do a minimal run
(eg: ./mozilla file:///your_test_case.html), and attach moz's output to this
bug report?
Target Milestone: mozilla0.9.2 → mozilla0.9.7
Sridhar, Brian:

Frank assigned this to me to help reproduce this problem. Since then Brian has 
created a patch with assistance from external contributors. 

I'd like to get this off my plate - Brian would you mind if I re-assigned this 
to you?

Sridhar, you have reopened this bug and we really need you cooperation to be 
able to determine how the nature of the problem has changed after Brian's most 
recent attempt to address it and whether it persists at all. We need to 
determine these criteria, otherwise it'll have to be closed in order to 
verified by Mozilla QA.

Comment 52

17 years ago
Sridhar: is your version before or after 2001-07-10 ?

Comment 53

17 years ago
2001-07-09 is when bug 63831 was fixed

I'm tentatively closing this. Please reopen, if you feel this is an incorrect 
decision and please follow-up with the info Brian requested if you have time.
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 55

17 years ago
Mark it as verified per comments above.
You need to log in before you can comment on or make changes to this bug.