Closed Bug 29726 Opened 26 years ago Closed 26 years ago

Bletcherous font rendering for <Hx> style fonts.

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 27378

People

(Reporter: bbehm, Assigned: erik)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.3.48 i686) BuildID: 2000022808 Any text I've seen rendered in Mozilla that's used as a header is rendered very poorly. I don't think this is an issue with my font/X server (as you can see by the screenshots, Netscape shows the fonts okay). This problem is sometimes seen for any big fonts. Ars Technica and CNN.com show the same problem with article headers. See http://members.home.com/bbehm/mozilla.png and http://members.home.com/bbehm/netscape.png to see a comparison between Mozilla and Netscape 4.72 displaying SlashDot. Reproducible: Always Steps to Reproduce: 1. Go to any site with HTML header tags (or virtaully any really big font) 2. Observe awful fonts Actual Results: See the screenshot http://members.home.com/bbehm/mozilla.png Expected Results: See the screenshot http://members.home.com/bbehm/netscape.png
A bit more information : The bug as shown occurs with the font setting at times/courier (which are Type1 fonts) and times new roman/courier new (which are TrueType fonts). They appear with either "Use my default fonts always" or "Use the page's fonts" selected. The bug shows up on text that isn't Header text, too : see http://members.home.com/bbehm/mozilla2.png for an example where it mangles text that uses the tag <FONT SIZE=2>.
Linux specific problem
Assignee: troy → kmcclusk
Not occuring for me on Debian GNU/Linux PowerPC (potato). But I've seen it in person on Mandrake 7 (on a friend's machine). I would say this is definitely a fontpath problem... or at least a problem with available fonts. Are your bitmap fonts setup ending in :unscaled (thus forcing the Xserver to Postscript fonts in the absence of appropriate sizes)?
My previous setup had all of my fontpaths as :unscaled, followed by the same fontpaths without that option. (This was the default RedHat 6.0 config). So I changed all of my fontpaths to :unscaled, as was suggested. Large text doesn't appear jagged anymore. But it does appear TINY. I've changed the font size for both my font server and mozilla->preferences, and header text (or large-size text) is still maybe 0.5-0.75 ems. I could post a screenshot if you like. Either way, changing my fontpath like this isn't necessary for Netscape, and as it breaks some other applications, I feel that while it may be a workaround, the bug still needs to be fixed.
Am getting this problem on my machine with the latest nightlies as well (Mandrake 7.0) - interestingly, my friend is not getting it in his Redhat 6.1 machine. Anybody know of font path or other differences betweek Redhat 6.1 and Mandrake 7.0 ? This might pin down the problem.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Erik, any ideas here?
Well, I have the very same problem on linux, but it is netscape 4.x that poorly displays web pages (ie: same bad scaled font, but in the body, not in the headers). Hence I would suspect an X configuration problem that pops into either browser because they choose slighly different fonts/size to render the same page. (However, mozilla should do its best to choose an non-ugly font, so I consider this as a bug anyway)
Re-assigning to myself.
Assignee: kmcclusk → erik
I've been playing with my fontpath and have managed to significantly narrow down where the problem lies. The following fontpath works correctly, and Mozilla renders the fonts as well or better than Netscape. --- Begin Correct Configuration --- catalogue = /usr/share/fonts/ttfonts, /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/75dpi, /usr/X11R6/lib/X11/fonts/100dpi, /usr/share/fonts/default/Type1, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/X11R6/lib/X11/fonts/freefont, /usr/X11R6/lib/X11/fonts/sharefont --- End Configuratoin --- Note that I have no evidence of the ':unscaled' operators having any impact on this problem : with the above fontpath, the problem does not appear with or without the ':unscaled' paths. The fontpath that was causing the problem (and this related to puetzk's suggestion) is /usr/X11R6/lib/X11/fonts/mdk. These fonts are all Helvetica style fonts. I am at the moment unsure of whether removing this directory makes helvetica style fonts unavailable, due to the flaky nature of the font selection dialog. But removing this directory from the fontpath makes the fonts render smoothly. I'm going to do some more tests, see if the problem directory works when set to :unscaled, see if Helvetica is available without that dir, and then get back to you all.
Removing the problem fontpath ( /usr/X11R6/libs/X11/fonts/mdk ) and therefore the Mandrake Helvetica fonts used therein does leave a helvita fontface available (at least on my system -- I think the Adobe Helvetica that is still available comes with XFree86, and therefore this shouldn't be an issue for most Linux users). Setting that fontpath to :unscaled will allow it to render larger text cleanly, but the text does not appear larger (I mentioned this previously) -- rendered cleanly, the Mandrake Helvetica fonts are much smaller than typical 12pt text, which makes them unsuitable for the headers/enlarged fonts for which they are chosen. So, the workaround to this problem is this : disable use of the Mandrake Helvetica fontfaces that are installed with Mandrake versions of XFree86-xfs. As far as fixing this bug so that it doesn't occur, I can only conjeture that the font server or Mozilla is making an error when determining the capabilities of this fontface. It would be nice to have this fixed, but I would suggest that the severity of this bug be changed to 'trivial'
*** This bug has been marked as a duplicate of 27378 ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
Marking verified dup of 27378.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.