Closed
Bug 158401
Opened 23 years ago
Closed 23 years ago
Applying font-family: monospace to PRE wrongly displays as sans-serif on screen
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: amonroe, Assigned: dbaron)
Details
Attachments
(5 files)
Screenshot: PRE not using fixed width font, 47k png
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID: 20020530
Here is my test case.
If my stylesheet contains a single line consisting of:
pre { font-size: 11px}
then the <PRE> text is rendered in my chosen monospace font (Lucida Console).
If I add font-family to my stylesheet:
pre { font-family: monospace; font-size: 11px}
The text within the <PRE> tags is wrongly rendered in my chosen sans-serif font
(Frutiger Linotype) instead of a monospaced font.
<HTML>
<head>
<link rel="stylesheet" href="mono3.css" type="text/css">
</head>
<BODY>
<P>s su ga os dubf awu be fiubais doufou ahsdofh o sod ogf aosudnof oa dougna
a ow daow dog oaunso do goa ojs do fo auwoe og oaunsou do fo ao wudofa w
a ow ud goaowndo of oauno sod of oau ou</P>
<P><PRE>s su ga os dubf awu be fiubais doufou ahsdofh o sod ogf aosudnof oa dougna
a ow daow dog oaunso do goa ojs do fo auwoe og oaunsou do fo ao wudofa w
a ow ud goaowndo of oauno sod of oau ou</PRE></P>
</BODY>
</HTML>
Reproducible: Always
Steps to Reproduce:
Copy & paste my text above into a sample .css and .html file. Try it both with,
and without the font-family spec.
Actual Results: Text in PRE tags rendered incorrectly when font-family was
specified.
Expected Results: Text in PRE tags should use my chosen monospaced font in both
cases.
|
||
Comment 1•23 years ago
|
||
example of <pre> without specifying font-family, font-family specified as
monospace and specified as sans-serif.
worksforme with linux build 20020719 and 1.0 release.
|
||
Comment 2•23 years ago
|
||
WFM too. (WinME 8-08 trunk)
|
Reporter | |
Comment 3•23 years ago
|
||
For a real world example page that fails, see:
http://www.roguelikedevelopment.org/development/dev00057.php
I will attach a screenshot showing the bug, comparing IE 4 to Mozilla 1.1 on Win 95.
I have duplicated the problem using the above URL on:
Mozilla 0.9 on Windows 2000
Mozilla 1.0 on Windows 98
Mozilla 1.1 on Windows 95
|
|
Reporter | |
Comment 4•23 years ago
|
||
|
|
Reporter | |
Comment 5•23 years ago
|
||
|
Assignee | |
Comment 6•23 years ago
|
||
What did you configure as your "Monospace" font in Edit | Preferences |
Appearance | Fonts? Is it a monospace font? (Is it a font whose metrics claim
to be monospace?)
|
|
Reporter | |
Comment 7•23 years ago
|
||
It's set to Lucida Console (at work, it MAY have been monotype.com - I'm at home
and can't check at the moment). It does appear correctly on the first of the 3
cases, as seen in the Screenshot of "reporter's testcase x3".
I checked just now, and changing to Courier New had no effect. Only the first of
the 3 cases in the above "testcase x3" file displays right.
|
|
Reporter | |
Comment 9•23 years ago
|
||
|
||
Comment 10•23 years ago
|
||
Looks like you have unticked "allow documents to use other fonts".
Tick it back to see what is happening.
|
|
Reporter | |
Comment 11•23 years ago
|
||
Good catch. Turning that on fixes (well, works around) the problem. I turned it
off and on a couple times, on two machines, to be sure.
What's involved in getting it to work even when it's unchecked? Does someone
need to duplicate my results and upgrade this to confirmed?
|
|
||
Comment 12•23 years ago
|
||
Could be a dup of bug 79074.
I wonder if fixing this bug might be done by just dropping any author's
font-family rules when parsing. In the case of <pre>, we want to keep applying
the rules in ua.css (or any user's rules in userContent.css), and this can't be
done merely via the fixup in nsRuleNode since the cascade has already mangled
the whole lot.
|
|
Assignee | |
Comment 13•23 years ago
|
||
Sure sounds like it (thanks to the -moz-fixed vs. monospace distinction -- is
that needed anymore given the new font-size code that recalculates up the tree?).
*** This bug has been marked as a duplicate of 79074 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 14•23 years ago
|
||
The author's "font-family: monospace" has already shadowed the -moz-fixed by the
time the check is being done. So the recomputation isn't kicking in (because of
the reset of generic = kGenericFont_NONE;)
Doing the handling at parsing time would also allow to replace
"fontname1, fontname2, generic" with "generic" as the other bug is requesting,
allowing to remove all the weak fixup that nsRuleNode is attempting.
|
|
Assignee | |
Comment 15•23 years ago
|
||
Parsing time is wrong though -- it messes with the CSSOM in a noncompliant way.
|
|
||
Comment 16•23 years ago
|
||
Ah, I see.
You need to log in
before you can comment on or make changes to this bug.
Description
•