Closed Bug 44677 Opened 24 years ago Closed 24 years ago

Overwrite: <sup>,<sup> and font interaction

Categories

(Core :: Layout, defect, P3)

x86
FreeBSD
defect

Tracking

()

VERIFIED DUPLICATE of bug 43214

People

(Reporter: jesup, Assigned: attinasi)

References

()

Details

(Keywords: fonts, platform-parity)

Attachments

(2 files)

Use the attached testcase for a minimal example.  the "New! Personal Desktop
Portal" line (table cell) overwrites the previous line; the exact amount depends
on font sizes and other layout issues.  If _either_ the <font ...> tag _or_ the
<sup> tag is removed, it lays out correctly.  Also an important note: with the
<font> tag, the <sup>SM</sup> doesn't get rendered at all.

I installed some additional fonts supposedly designed for Mozilla (and Netscape
4.x) under Linux/etc; I don't know if they'd have an effect.  I got them from
this place:  http://fox.mit.edu/skunk/xwin/#mozilla_fonts
See also bug # 43250

This is related to the Arial font it appears (see the second testcase).

This is from the website mentioned before.  Note that Arial is not mentioned...
I have Xfree86 3.3.5.

mozilla-fonts is a complete set of the three kingpin typefaces in Httpland--
Times, Helvetica, and Courier-- each in two weights, two slants, and seven
sizes (for a grand total of 84). The sizes range from 13- to 57-point (all @
100dpi) and have been individually selected to match the font display behavior
of
MS-Windows Netscape as closely as possible. Right down to the glaring scale
disparity between sizes 6 and 7. 
*** Bug 43250 has been marked as a duplicate of this bug. ***
Given the output, I'm guessing that an X font call (size of a string) is failing
and the size of the string is uninitialized.  This triggers the assertion
failures seen in bug 43250.  Just a guess, but it makes sense.  Could be some
other call involved in <sub> and <sup>, though.

###!!! ASSERTION: illegal height for combined area: 'aCombinedArea.height >= 0',
file nsLineBox.cpp, line 408
###!!! Break: at file nsLineBox.cpp, line 408

Changing the summary to be more descriptive.
Summary: Table overwrites previous line: <sup> and <font> interaction → Overwrite: <sup>,<sup> and font interaction
It's possible that this also causes memory corruption: see bug 44777.
This bug is closely related to bug 43214 - in that case it causes a crash.
Marc, could you have a look at this?
Assignee: clayton → attinasi
This is X only, right?
Keywords: fonts, pp
I've only seen it with X, however the bug might not be in X-specific code
(something higher up may be ignoring a return code from a lower-level font
routine).  If I had to guess I'd say it was X-specific.
Without installing the fonts mentioned there are no problems (assertions or 
misbehaviors). I am d'loading the fonts now, even though Arial is not among them 
(apparently).

It works fine on NT (where Arial is installed, of course).
OK - I installed the fonts (binary RPM) and reran the tests. They both look fine 
. In both testcases the output looks valid, and I am not getting any assertions 
or errors on the console (using 7/27 fresh-pull). Also, the testcase for related 
bug 43214 works fine as well. Was this fixed?
It still fails for me - fresh checkout/build today (7/27).  Eric Pollmann _does_
see the crash for 43214, so he'd be a good person there to re-check this one. 
Perhaps it's a FreeBSD thing (I'm guessing from the RPM reference you're running
Linux)?  Also, I didn't install from RPM's (of course); perhaps there's a
difference in the installs.
Oh, I missed that OS thang - Yes, I'm running Linux 6.2

We have no FreeBSD installations down here in the SD office - can somebody with 
the appropriate OS take this one over? Pollman?
Whiteboard: (py8ieh:um, install FreeBSD to check this...)
I see both the crash bug (bug 43214) and this bug on Linux as well as FreeBSD. 
The fonts must be:
 1) installed
 2) have makefontdir run in the directory they are installed in
 3) xset +fp (directory they are installed in)

A way to tell if they are installed or not is that the text "SEARCH" to the
right of the URL bar will be abnormally large, and if you run netscape 4.x, all
of the text in the chrome will be abnormally large.  I have unzipped and
untarred mozilla-fonts.tar.gz into /u/pollmann/public/mozilla-fonts, and run
makefontdir, so on a Linux box you should only have to xset +fp
/u/pollmann/public/mozilla-fonts then run apprunner to see the problem.

Something is very funky with these fonts...  (or our handling of them)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks, Eric, I have the fonts working now on Linux (the RPM didn't add the 
fonts to the fontpath...). Now I need to debug it.

Ian, you really shouldn't need to install FreeBSD unless you still want to - we 
can repro on Linux now.
Status: NEW → ASSIGNED
Marc: Ok. I probably will anyway though, if I get the time (post nsbeta2, that's
for sure...).
Whiteboard: (py8ieh:um, install FreeBSD to check this...)
...or, if you want to use my FreeBSD 4 machine, feel free!  It's in my cube or
remotely at h-208-12-36-172.mcom.com (I've requested a static IP but haven't
recieved one yet)
See latest comments for bug 43214.  This bug (or that one) should be marked as a
dup.  The problem is that the font has a bad X_HEIGHT property (of 0xfffffffe).
Excellent work, Randell Jessop! Thanks very much for tracking this down. It 
looks like bug 43214 has all of the information, so I'm marking this a dup of 
bug 43214. Thanks!

*** This bug has been marked as a duplicate of 43214 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
massive update for QA contact.
QA Contact: petersen → lorca
Marking VERIFIED.
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: