Closed Bug 195573 Opened 22 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: