Closed Bug 195573 Opened 23 years ago Closed 19 years ago

Links not underlined when using TrueType fonts

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: masonian, Unassigned)

References

Details

(Keywords: relnote, Whiteboard: [bug in Xfree86 V4.3.0])

Attachments

(1 file)

Patch to XFree86-4.3.0 fixing UNDERLINE_POSITION sign
771 bytes, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 When a typeface is changed to use a TrueType font (such as monotype-times new roman, monotype-arial and microsoft-verdana), links on web sites which use that typeface are not underlined regardless if "Underline Links" is checked or not. Reproducible: Always Steps to Reproduce: 1. Go to Edit -> Preferences -> Appearance -> Fonts 2. Change Serif to monotype-times new roman 3. Go to www.mozilla.org or Help -> About Mozilla Actual Results: Links are not underlined Expected Results: Links should be underlined The fonts I used were obtained from a standard Windows 98 installation with the XFree86 4.3.0 freetype module as the rasterizer. If you do not have these fonts, you have obtain them for free at this link: http://corefonts.sourceforge.net/
WFM, day old CVS, Linux. Are you using an experimental build? (Xft/Gtk2)
Confirm: rv:1.2.1 Gecko/20021217 Linux i686 Indeed, this is an artefact of the updated FreeType font rasterizer in XFree86-4.3.0. For the fonts rasterized with FreeType (i.e. Type1 and TrueType) it now provides in particular UNDERLINE_POSITION property, which for most fonts on my system is negative. Mozilla seems to use this property when available, however it is assumed to be unsigned. The problem is apparently relevant to the builds using server-based fonts, not gtk2/Xft.
For reference, see bug 11168.
Component: Layout: Fonts and Text → GFX: Gtk
In XFree86-4.3.0 the sign of UNDERLINE_POSITION flipped, dunno whether intentionally or not. See xc/lib/font/FreeType/ftfuncs.c. So the question is where it should be fixed - in XFree86 or in mozilla.
So should we just assume the change was intentional and start taking the absolute value? (I'd rather not make the change myself since I can't test it, but it should be easy enough for someone who can test it. See bug 11168 for the location of the code.)
XFree86 people (namely Juliusz Chroboczek) seem to have recognized this as a bug in XFree86-4.3.0 and recommended my patch restoring the previous behavior for inclusion. Once it is comitted to the XFree86 CVS this bug should be closed. See the patch attached.
*** Bug 196574 has been marked as a duplicate of this bug. ***
The fix is in XFree86 CVS as of 2003/04/03 (just noticed). Please close the bug.
*** Bug 204899 has been marked as a duplicate of this bug. ***
*** Bug 198706 has been marked as a duplicate of this bug. ***
Whiteboard: [bug in Xfree86 V4.3.0]
Just curious: Does it make sense to stick this into the release notes ?
Keywords: relnote
Seeing this in 1.4 and 1.5b under Mandrake 9.1 (stock) Test site: google.com -- All the links are not underlined. If I go Preferences -> Appearance -> Fonts -> Uncheck "Allow Documents to use other fonts" Then the underlines show back up.
I just ran into this myself after upgrading to Slack 9. It took about an hour of poking at configuration files and/or googling to find this page and get an explanation. XFree86-4.3.0 has been out since Feb 27 2003, which means it's had six months to make its way into various Linux distributions. I suspect lots of people have or will run into this. In the short term, a remark in the release notes would be helpful. In the medium term, I think David Baron's suggestion to have Mozilla work around the broken behavior of UNDERLINE_POSITION is a good one. It's a lot easier to upgrade Mozilla than to upgrade/downgrade XFree86.
Why does the underline show-up when I run the mouse over the text [1.4 20030624]? Note, even with "Underline Links" checked, the links are not underlined, so I appear to be affected by this issue. Is the underlining during a mouseover being done differently already?
Scott McPeak wrote: > In the short term, a remark in the release notes would be helpful. In the > medium term, I think David Baron's suggestion to have Mozilla work around > the broken behavior of UNDERLINE_POSITION is a good one. It's a lot easier > to upgrade Mozilla than to upgrade/downgrade XFree86. Erm... no. If we would start adding workarounds in Mozilla for all possible OS bugs mozilla would become a bloated mega-size monster-executable. At some point there should be a tradeoff between "adding workarounds for OS bugs in mozilla" vs. "let users apply patches". AFAIK Xfree86 staff was fixed this issue long ago in their tree and the patch updates for Xfree864.3.0 include the fix as well - it's only the Linux distrib which has to update it's Xfree version - and AFAIK most of them did that already (OK, except your one... :)
I agree one must draw the line between modifying Mozilla to suit the environment and modifying the environment to suit Mozilla. In this case, I'm suggesting that this bug deserves to be on the "modify Mozilla" side of the line. Let me explain why: First, it's a major cosmetic issue. People expect links to be underlined, and there's a user-pref that promises to do it. Second, it's not apparent which piece of software is at fault. When links aren't underlined, but underlining works fine in other software, Mozilla is likely to get the blame. (And here we are, discussing it in Mozilla's bugzilla.) Third, though I admit I can only guess, I think a lot of linux users will be bitten by this. If your distribution is aggressive about staying on the bleeding edge and you're aggressive about keeping up with all the distro's patches, or you build from source (rather than using xfree86.org's binaries), you're ok. Otherwise, pow. We're debating in the absence of data, namely how many users will have this problem. This bug has three votes and three dupes. Maybe that isn't an army, but it's more than just me. Finally, the fix in question (as I understand it) - is easy to make, and easy to test (if you have XFree86-4.3.0) - won't make Mozilla bigger by more than one assembly instruction - is unlikely to become, itself, the source of a future bug and workaround (to my view, the biggest danger in such things) I already downgraded to 4.2.0, and Linux users are more or less forced to use Mozilla anyway, so maybe it's moot. But it seems to me that if you make any set of criteria for deciding when to adapt and when to refuse to adapt, other than "never adapt", this situation will fall into the former category.
*** Bug 222443 has been marked as a duplicate of this bug. ***
actually, not many linux users would be affected because most linux distributions these days ship Xft build of Mozilla instead of the default X11core font build.
Can we close this bug ? AFAIK this issue has been fixed in the various Linux distributions and Xfree86 trunk and 4.3.x branch since a long time...
*** Bug 244846 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051224 Firefox/1.6a1 Works for me using gtk2.8 and X 6.8.2.
(In reply to comment #20) > Can we close this bug ? AFAIK this issue has been fixed in the various Linux > distributions and Xfree86 trunk and 4.3.x branch since a long time... Now that we're three years past the original bug and fix to XFree86, and many (most?) distros have switched to x.org anyway, and almost two years since the last dup, I'd vote to close it. Works for me: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 x.org 6.8.1 (slack 10.1)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: