8.26 KB, image/png
136 bytes, text/html
1.26 KB, text/plain
1.26 KB, text/plain
xlsfonts -u dump on testcase system (XFree86 fonts, Microsoft Web Fonts and IBM JRE TrueType fonts) -- in the testcase, Microsoft's fonts were used
101.67 KB, text/plain
230 bytes, text/html
249 bytes, text/html
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.
*** Bug 59873 has been marked as a duplicate of this bug. ***
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.
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.
Reporter is this still a problem with the latest nightlies?
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.
Marking NEW as per comments.
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.
I can't believe that's marked a bookmarks bug! Moving to Layout - might not be right, but surely better than bookmarks...
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...
seems this is a Verdana vs. Arial issue for me - perhpas Verdana is using Unicode and Arial doesn't?
layout => karnaze.
*** Bug 78253 has been marked as a duplicate of this bug. ***
*** Bug 76625 has been marked as a duplicate of this bug. ***
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.
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. ***
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. ***
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. ***
Reassigning to ftang.
reassign to bstell. cc email@example.com mark it as moz0.9.2
frank, do you know who sohuld be the QA for this bug b/c it sure isn't me?
Is this a dup of 78643 ? Can some one try the Comments From firstname.lastname@example.org 2001-06- 09 11:00 in bug 78643 ?
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.
pdt+ base on 6/11 pdt meeting.
*** Bug 86470 has been marked as a duplicate of this bug. ***
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
Created attachment 39217 [details] Log of font requests while loading the testcase (NS_FONT_DEBUG=5)
Created attachment 39218 [details] Log of font requests while loading the testcase (NS_FONT_DEBUG=5)
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
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.
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.
jbetak- can you try to set up the test environment and reproduce this problem. talk to email@example.com . she seems install the font once.
my last comment: >talk to firstname.lastname@example.org . she seems install the font once. Sorry. I am confused with another bug.
is this the same bug as bug 78643?
is this the same bug as bug 63831?
I looks like a dup of 78643 and 63831
If this is a dup, please mark it so. Otherwise, please add eta to status whiteboard.
mark it as dup of 78643 *** This bug has been marked as a duplicate of 78643 ***
Created attachment 41518 [details] html; A very simple testcase specifying a freetype-arial-10646-1 font
Created attachment 41519 [details] slightly revised simple testcase specifying a freetype-arial-10646-1 font
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
the fix for bug 63831 (now checked in) should fix this.
Switching QA contact to ylong. Yuying, can you verify that the fix for bug 63831 also fixes this problem? Thanks.
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.
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).
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?
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.
Sridhar: is your version before or after 2001-07-10 ?
2001-07-09 is when bug 63831 was fixed
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.
Mark it as verified per comments above.