59915 - Failing to calculate width of TrueType fonts on XFree 4.0

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Ilya Konstantinov]

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

[Ilya Konstantinov]

Attachment: Demonstration on the problem as seen on www.google.com

Comment 2

[Boris Zbarsky [:bzbarsky]]

*** Bug 59873 has been marked as a duplicate of this bug. ***

Comment 3

[Ilya Konstantinov]

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

[Ilya Konstantinov]

NOTE!
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
present.

Comment 5

[Keyser Sose]

Reporter is this still a problem with the latest nightlies?

Comment 6

[Ilya Konstantinov]

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

[Keyser Sose]

Marking NEW as per comments.

Comment 8

[Robert Kaiser]

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"
http://trolls.troll.no/~lars/xparts/) - I can't even look at some file names at
mozilla.org 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.

Comment 9

[Robert Kaiser]

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

Moving to Layout - might not be right, but surely better than bookmarks...

Comment 10

[Robert Kaiser]

hmm, interstesting.
I'm seeing this at http://www.mozillazine.org/ which uses lots of <font
face="Verdana, Arial, Helvetica, sans-serif"> tags - but I'm not seeing this on
my own pages (http://www.kairo.at/) 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

[Robert Kaiser]

seems this is a Verdana vs. Arial issue for me - perhpas Verdana is using
Unicode and Arial doesn't?

Comment 12

[Viswanath Ramachandran]

layout => karnaze. 

Comment 13

[Cory Dodt]

*** Bug 78253 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 76625 has been marked as a duplicate of this bug. ***

Comment 15

[Cory Dodt]

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

[Ilya Konstantinov]

I hope it won't be the final "solution" to this bug, since some of us actually
need those iso10646-1 font entries.

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 78693 has been marked as a duplicate of this bug. ***

Comment 18

[Miles Lane]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 78469 has been marked as a duplicate of this bug. ***

Comment 20

[D. Travis North]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 79625 has been marked as a duplicate of this bug. ***

Comment 22

[karnaze (gone)]

Reassigning to ftang.

Comment 23

[Frank Tang]

reassign to bstell. cc [e-mail]
mark it as moz0.9.2

Comment 24

[Claudius Gayle]

frank, do you know who sohuld be the QA for this bug b/c it sure isn't me?

Comment 25

[Frank Tang]

Is this a dup of 78643 ? Can some one try the Comments From [e-mail] 2001-06-
09 11:00 in bug 78643 ?

Comment 26

[Ilya Konstantinov]

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

[Frank Tang]

pdt+ base on 6/11 pdt meeting.

Comment 28

[Boris Zbarsky [:bzbarsky]]

*** Bug 86470 has been marked as a duplicate of this bug. ***

Comment 29

[kill this account]

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.

thanks

Comment 30

[Ilya Konstantinov]

Attachment: A very simple testcase.

Comment 31

[Ilya Konstantinov]

Attachment: Log of font requests while loading the testcase (NS_FONT_DEBUG=5)

Comment 32

[Ilya Konstantinov]

Attachment: Log of font requests while loading the testcase (NS_FONT_DEBUG=5)

Comment 33

[Ilya Konstantinov]

Attachment: 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

[Ilya Konstantinov]

Brian,

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

[pete]

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
file)

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

[Frank Tang]

jbetak- can you try to set up the test environment and reproduce this problem.
talk to [e-mail] . she seems install the font once.

Comment 37

[Frank Tang]

my last comment:
>talk to [e-mail] . she seems install the font once.
Sorry. I am confused with another bug.

Comment 38

[kill this account]

is this the same bug as bug 78643?

Comment 39

[kill this account]

is this the same bug as bug 63831?

Comment 40

[Frank Tang]

I looks like a dup of 78643 and 63831

Comment 41

[selmer (gone)]

If this is a dup, please mark it so.  Otherwise, please add eta to status
whiteboard.

Comment 42

[Frank Tang]

mark it as dup of 78643

*** This bug has been marked as a duplicate of 78643 ***

Comment 43

[kill this account]

Attachment: html; A very simple testcase specifying a freetype-arial-10646-1 font

Comment 44

[kill this account]

Attachment: slightly revised simple testcase specifying a freetype-arial-10646-1 font

Comment 45

[kill this account]

would any developers who see this problem try this fix for bug 63831
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=41534
and see if it also fixes this bug?

thanks

Comment 46

[kill this account]

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

Comment 47

[Andreas Becker]

Switching QA contact to ylong.  Yuying, can you verify that the fix for bug
63831 also fixes this problem? Thanks.

Comment 48

[Yuying Long]

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

[Sridhar Dhanapalan]

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).

Comment 50

[kill this account]

Sridhar:

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?

Comment 51

[[e-mail] (away - not reading bugmail)]

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

[kill this account]

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

Comment 53

[kill this account]

2001-07-09 is when bug 63831 was fixed

Comment 54

[[e-mail] (away - not reading bugmail)]

Sridhar,

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.

Comment 55

[Yuying Long]

Mark it as verified per comments above.