Closed
Bug 11168
Opened 25 years ago
Closed 25 years ago
[PP] Inconsistent/ugly TrueType font underlining on different platforms
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: dr, Assigned: dbaron)
References
()
Details
(Whiteboard: fixed attached -- fix being checked in)
Attachments
(5 files)
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Underlined links in the font "Trebuchet MS," which is used on mozillaZine,
appear way too high up, almost as if intended as strike-through lines. This is
likely a symptom in other TrueType fonts as well. I am using RH6 default xfree
and xfs (w/truetype), but I don't believe those to be the problem since NC4.5
renders these links properly.
this may be a specific instance of a more generic bug having to do with
underlining fonts. see bug 11101 for what is possibly another case of the same
bug...
also unsure whether this is a linux/unix/xfree/x-specific bug (does it work ok
under windows, mac?...) in layout, or whether it would be better off in
xptoolkit.
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] klein_sh@inter.net.il
Summary: ugly link underlining in trebuchet font → Ugly TrueType font underlining on Linux(*nix?)/X
Changing summary for a more accurate description :)
BTW, now might be a good opportunity to mention that not everybody has "verdana"
on their system, which seems to be the standard font for the apprunner ui... Is
there any proposed solution to either settle on a standard URW font or
distribute a font with the final browser product?...
arrgh, sorry. there may be a bugzilla bug -- the browser stalled when i hit
submit, and i thought the submission wasn't processed.
Actually, it looks like the underlines are too low on windoze as well. There is
some funky code in there that makes up the underline offset and its not clear
what it's doing...
OS: Linux → All
Hardware: PC → All
Summary: Ugly TrueType font underlining on Linux(*nix?)/X → [DOGFOOD] [PP] Inconsistent/ugly TrueType font underlining on different platforms
Again, changing the summary and platforms according to kipp's last comment, and
marking for platform parity and eating our own dogfood... Just curious why this
has been pushed back to M15 as well?...
Assignee | ||
Comment 9•25 years ago
|
||
This is a rather serious bug on Linux:
http://www.hotbot.com/
http://www.mozillazine.org/
http://www.fas.harvard.edu/~dbaron/
etc.
Comment 10•25 years ago
|
||
Comment 11•25 years ago
|
||
Can I get a copy of the offending font? My PC's at home don't have it :-(
I can't reproduce the sheer uglyness of your attachments without out :-)
Reporter | ||
Comment 12•25 years ago
|
||
Trebuchet MS (as well as Verdana and a bunch of others) are all Microsoft "web
core fonts" which you can find at
http://www.microsoft.com/typography/fontpack/default.htm. Unfortunately, they're
only compressed as mac stuffit or pc self-installers, but if you can grab the
.ttf files out of them somehow (and run a truetype font server on your linux
box) that should work for you just fine...
The only thing that comes to mind is, perhaps the font server isn't behaving
well... but I doubt that since it renders underlines in the same fonts in Nav4
just fine :)
Assignee | ||
Comment 13•25 years ago
|
||
I believe the underline is drawn by Mozilla, not the font server. I don't know
if that was true in 4.x.
Actually, NN 4.x has serious problems dealing with correctly served (xfsft) TT
fonts (as opposed to TT fonts served by xfstt, which I believe have some metrics
kludged).
Summary: [DOGFOOD] [PP] Inconsistent/ugly TrueType font underlining on different platforms → [PP] Inconsistent/ugly TrueType font underlining on different platforms
Comment 14•25 years ago
|
||
[DOGFOOD] designation removed.
Assignee | ||
Comment 15•25 years ago
|
||
Is there actually a problem here on Win? I've never seen it, although kipp
commented about underlines being too low. Or is this just a Linux bug?
Reporter | ||
Comment 16•25 years ago
|
||
Wow, we really need to get our story straight.
Okay, here's the problem I noticed originally: The font underlining on the linux
platform in the Trebuchet MS and Verdana typefaces was way too high up, almost
as high as the line in strike-through text. Kipp then mentioned that underlines
seemed too low on Windows, so I changed the summary to "inconsistent across
different platforms" rather than specific to linux.
I don't have access to a Linux box at this moment, so I can't comment. On Win32
I have noticed the underlining is a tiny bit low (which makes menu items
uncomfortably wide from a UI perspective) and the same on Solaris, when it
manages to build ;-)
If somebody has access to a Linux box, put the MS "core web fonts" I mentioned
on it, and run apprunner. If it comes out looking like the first two screenshots
attached to this bug (note: NOT the third, because that's with helvetica
substituted for trebuchet) then it is still broken. And M17 isn't the right
milestone for this bug. If it comes out looking okay (screenshots baby!) then
resolve it as fixed.
Ooh yeah.
Assignee | ||
Comment 17•25 years ago
|
||
Perhaps this bug should be only for the problem of underlines being too high
(Linux), and the bug for too low (less serious) should be separate?
Assignee | ||
Updated•25 years ago
|
Target Milestone: M17 → M12
Assignee | ||
Comment 18•25 years ago
|
||
The fix for this is painfully simple. It's one character: "-". I'm changing
the milestone to M12 and I'll attach the fix.
cc:ing erik, since he owns the code (I think - I didn't actually check cvs blame
or anything).
Assignee | ||
Comment 19•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] klein_sh@inter.net.il → fix attached [MAKINGTEST] klein_sh@inter.net.il
Assignee | ||
Comment 20•25 years ago
|
||
BTW, the reason this wasn't much more obvious (when the code was written, I
guess) was that it only affected TrueType/Postscript fonts since other fonts
don't have built-in underline offset information.
Assignee | ||
Comment 21•25 years ago
|
||
I just realized - one other reason this might not have been noticed is that
either xfstt or xfsft is returning the negative of what it should be. Someone
who is using xfstt should check that this patch works OK. (Both people who
claim to have seen it use xfsft, which comes with RH 6.0.) If the two font
servers are returning negatives of each other, then you'll just need to use an
absolute value (or negative thereof).
(However, it also could be that xfstt doesn't return the info at all, and
therefore the other code path is used...)
Assignee | ||
Updated•25 years ago
|
Whiteboard: fix attached [MAKINGTEST] klein_sh@inter.net.il → fix attached
Assignee | ||
Comment 22•25 years ago
|
||
Kipp, did you see this bug when you got the fonts installed? (Since you have
xfstt, that'll answer my question in my previous comment.)
Assignee | ||
Comment 23•25 years ago
|
||
OK... I switched my font server to xfstt, and it xfstt doesn't return underline
offset information (by using the printf in the code right below my fix). That's
why this bug shows up only with xfsft. This also means the fix shouldn't have
any effect on xfstt.
I don't have any postscript fonts with AFM's (I assume that's what you mean by
"afm fonts"), so I can't check those. Pavlov, you wrote the comment about "afm
fonts" - did you ever test them with underlines, or did you find out from
someone else that the code was being used for afm fonts?
Anyway - I think this fix should be checked in soon unless someone has PS fonts
with AFM's and sees a problem...
I'll attach a revised patch with the comment corrected!
Assignee | ||
Comment 24•25 years ago
|
||
Assignee | ||
Comment 25•25 years ago
|
||
If you search for XA_UNDERLINE_POSITION in
http://vireo.gatech.edu/ebt-bin/nph-dweb/dynaweb/SGI_Developer/XLib_PG/@Generic__BookTextView/14689;cd=2
, it's clear that the UnderlineOffset should be returned as a positive number
(and it's not an xfsft bug). (I think in Windows it should be returned as a
negative number, since there's no minus sign in the Windows code). Mozilla
seems to be using it as though it should be negative. (Unless the bug is really
somewhere else - i.e., the font rendering code...)
Assignee | ||
Comment 26•25 years ago
|
||
To answer my previous parenthetical comment, nsTextFrame::PaintTextDecorations
clearly assumes that the underline offset is negative, since it subtracts
(lowers) it from the vertical position of the top of the underline. And,
furthermore, it's XP code.
Updated•25 years ago
|
Assignee: kipp → pavlov
Status: ASSIGNED → NEW
Comment 27•25 years ago
|
||
taking bug since kipp doesn't work here anymore
Comment 28•25 years ago
|
||
Mass-moving non-PDT+ bugs to M13
Reporter | ||
Comment 29•25 years ago
|
||
By the way, I'm not even positive this is a truetype bug at all... I get the
same problem on Solaris (these systems do not have truetype, to my knowledge)
with text styled through CSS as sans-serif, italic. This may be a problem with
standard URW fonts then, also. If somebody applies the fix attached, I could
verify it quickly and have this bug be a distant memory far before M13 rolls
around... Any takers?
Assignee | ||
Comment 30•25 years ago
|
||
It's a problem with any fonts that claim to have metrics for underline offset
info (which many do not).
Pavlov, could this be checked in? It's one character...
Updated•25 years ago
|
Whiteboard: fix attached → fixed attached -- fix being checked in
Comment 31•25 years ago
|
||
looks good to me
Assignee | ||
Updated•25 years ago
|
Assignee: pavlov → dbaron
Assignee | ||
Comment 32•25 years ago
|
||
Assigning to self, since I just checked in the fix (2000-01-11 18:24PST).
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 33•25 years ago
|
||
BTW, does anyone else see any problems with the underline metrics guessing code
on other platforms? It's certainly fine on Unix. Kipp made some vague comments
about it on windows, but I would guess that Windows is using metrics from the
fonts.
But marking fixed (see previous comment), since the main point of this bug is
fixed, and it's not clear if there are any other bugs. (There's only a comment
from Kipp that he thought the underline on Windows was too low. However, the
underline metrics for the particular font involved (Trebuchet) are low, which is
why they looked so bad when reversed in sign.)
Comment 34•25 years ago
|
||
Works fine in the Feb 01 build. Marking verified fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•