Open Bug 175415 Opened 22 years ago Updated 2 years ago

multiple generic fonts (font: monospace,serif) cause unexpected variation of font-size

Categories

(Core :: CSS Parsing and Computation, defect, P4)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

People

(Reporter: felipe, Unassigned)

References

(
URL
)

Details

(Keywords: css1, testcase, Whiteboard: [CSS1-5.2.2])

Attachments

(2 files)

testcase. Must set different sizes for "normal" and "fixed-width" text to test
237 bytes, text/html
Details
Complete, self-explanatory testcase
1.80 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021016

Compare this page to http://fgmusic.org/~fgasper/mass_pts/header2.html. The only
difference between the two is that the regular one has <body style="font-family:
monospace, generic"> declared, whereas header2.html only has "monospace" listed.
Moz should be taking monospace from both, but instead it appears to use
"generic", which yields a bigger monospace font for me. Works correctly in IE.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Hmmm. "generic" is not a generic font-family per the CSS2 specification, so that
isn't doing you any good. But whitespace is not required after the comma in the
listing of font-families, as I read CSS2, so both of the documents should have
the generic font-family "monospace" applied, AIUI. dbaron?
Assignee: asa → dbaron
Status: UNCONFIRMED → NEW
Component: Browser-General → Style System
Ever confirmed: true
QA Contact: asa → ian
Summary: Moz won't take "monospace" in CSS → Variation in computed font-size on monospace font
I don't see a problem.  If there is one, it seems like it would be in the
windows font code.  ->shanjian
Assignee: dbaron → shanjian
Keywords: css1
Actually, this is a rulenode problem, and it's XP.  Steps to reproduce:

1)  Open preferences
2)  Set font size for "variable-width" to 16px
3)  Set font size for "fixed-width" to 10px
4)  Open the testcase I'm about to attach.

The problem is the code in nsRuleNode::ComputeFontData that sets the size and
such based on the "generic family".  Currently it does:

    nsFont::GetGenericID(font->mFont.name, &generic);

Of course when there are multiple families listed font->mFont.name is the full
list, so "generic" is false.  We then end up applying the "normal" font size
instead of the "fixed-width" one.... (this explains some trouble we had once
with -moz-fixed not being recognized for sizing purposes if any other
font-families were listed, btw).

So the problem is that the whole setup is flawed.  There could be multiple
generic families listed in the decl, etc.

Perhaps Hixie is right and we should eliminate the "two different font sizes"
thing, except it's very convenient from a user perspective....

If we knew at style-resolution time which family we would use, we could use that
information... but we don't know that at that point, do we?
Assignee: shanjian → dbaron
OS: Windows 98 → All
Hardware: PC → All
One way to fix this would be to make '-moz-fixed' not a font-family but a
special font shorthand like we do for '-moz-dialog', setting:
   font-size: 1em
   font-family: monospace
   font-size-adjust: /x/
...where /x/ is the ratio of the default font size to the fixed font size.

Or we could just drop the whole multiple font size idea.
Actaully, this has nothing to do with -moz-fixed.  This is the standard CSS
"monospace" font-family.  If it occurs alone, we use the "monospace" font size
from prefs; otherwise we use the "everything else" font size.
That should definitely change then; 'font-family: monospace' shouldn't cause any
change of 'font-size' and should not affect 'font-size-adjust'.
Dupe. It is the same issue as bug 78517, and is one aspect of bug 79074. See
also bug 105297.

Parsing is needed to figure out the generic font of a font-family list at style
resolution. Not much incentive to do that since style resolution is often blamed
for speed.

Perhaps the speed isn't that bad these days, and parsing could be done. Or
perhaps the fontdata could be changed so that it keeps an atom list of font
names. This way, the parser does the parsing once, allowing anybody to lookup
the list without re-parsing.
<p style="font-family: 'No such family, man', monospace">Some text (bigger)</p>

Also, this illustrates how the problem is much trickier than it seems. In the
above example, it is clear that the monospace font is what is going to be
ultimately used by the font subsystem when it realizes the actual fonts. But if
the style resolution has to check for existence of the fonts in each font-family
list in order to make much finer decisions, then it is just going to crawl (in
the current setup where there is no internal db/history of fonts).
Yet another reason not to have any sort of magic here.
Worse yet: "font-family: sans-serif, monospace"....

Hixie, feel free to suggest an alternate approach.  Perhaps we need to let the
user select font-size-adjust for the different generic font-families?  That
would be arcane to the point of being ridiculous.  Can Mozilla calculate
font-size-adjust based on the font metrics somehow?
Keywords: testcase
Priority: -- → P3
Hey, I have a radical idea here, why don't we do what the spec says and only
have one font size?
Priority: P2 → P3
Priority: P3 → P2
> Worse yet: "font-family: sans-serif, monospace"....

Actually, it isn't any worse (the common root problem is the parsing -- and the
existence constraint).

> Hixie, feel free to suggest an alternate approach.  Perhaps we need to let the
> user select font-size-adjust for the different generic font-families?  That
> would be arcane to the point of being ridiculous.

There are already hidden prefs to do that :-) But they only work on Windows.

> Can Mozilla calculate font-size-adjust based on the font metrics somehow?

Yes. If desired, the font subsystem can be made to pick automatic values on the
fly to force a perfect match of all 'x' across _individual_ fonts. See the
second line in the demo on attachment 38875 [details] on bug 74186 (which is the bug that
you might read if you are interested in getting more background on the issue).

People want different sizes because certain fonts are designed very differently.
As attachment 38875 [details] shows, the text on the first line is unreadable with the
cursive font if it is rendererd with the same actual size as the Verdana font.
Conversely, the Verdana text would be huge if the (common) size was chosen so as
to make the cursive text readable. Summary: it is not going to be acceptable to
set a single size without means to compensate in certain fonts.

The reason why Hixie's idea of using the font-size-adjust hasn't materialized so
far is because font-size-adjust is only implemented on Windows. Hence rather
than switching to the spec way and breaking everybody else, we had little choice
than emulating by other means which have their own limitations. If other
platforms can implement font-size-adjust, then that will provide a common
foundation to try other things.
So could you provide a brief rundown in what's involved in implementing
font-size-adjust?  It sounds like it's implemented in the platform-specific
font-selection code?  Any way to hoist it out of there?
Unfortunately, it cannot be factored out because it is deadly tied with
font-switching (i.e., glyph lookup). 

<excerpt from bug 74186 comment #24>
[...]

If you have some peculiar scenarios, such as:

   <div style="font-family: HebrewFont, RomanFont; font-size: 16px; 
               font-size-adjust: 1.0;">
      Some Hebrew Text  Some Roman Text
   </div>

...and the HebrewFont has an aspect ratio of 2, and the RomanFont has
an aspect ratio of 0.5, and the relevant pieces of text are drawn in
their respective fonts after glyph lookup, then the computed font
size will be 16px all the way through, but "Some Hebrew Text" will
have an actual font size of 8px, and "Some Roman Text" will have an
actual font size of 32px.

[...]
</excerpt>
Instead of multiple font sizes, we should just auto-detect the aspect ratio of
the user's main choice font (call it 'x'), and then synthesise the following
rule in the user's preferences stylesheet:

   :root { font-size-adjust: x; }

That would automatically take care of making things like <pre> the right size.
We could even do that before other platforms support font-size-adjust, since it
basically falls back on what I've been suggesting for all platforms, which is to
drop this whole notion of multiple font sizes.
Ian, perhaps my understanding of font-size-adjust is faulty.... how does  :root
rule solve the problem in the following situation?

<html>
This is some text.  It should be serif, not too big and readable -- default font.
<pre>
This is some text in pre.  It should be monospace, not too big, and readable --
default monospace font
</pre>
<p style="font-family: fantasy">This is a fancy script font that's probably hard
to read at small sizes.  This part should be readable too</p>
</html>

It seems to me that we should be applying the calculated font-size-adjust for a
generic family to _any_ element to which we apply a generic family....

I agree that we can (and should) put the font-size-adjust stuff in place and
test it on Windows before it's even implemented on other platforms...
font-size-adjust inherits.
Ah.  I see... I just re-read that part of the spec, and that _should_ indeed
work....
To test, just (manually) add Hixie's rule to html.css for a moment:
  :root { font-size-adjust: 0.55 } (or xheight/font-size in general)

I've been using that rule for several months now with no ill effects.
Blocks: 205537
Assignee: dbaron → nobody
QA Contact: ian → style-system
Hello all,

I read carefully all of the comments in this bug and then the summary and description of bug 205537 and I am convinced this bug and bug 205537 are *_exactly about the same issue_*. I believe+wish this bug could be resummarized to better reflect the issue here.
Summary: Variation in computed font-size on monospace font → multiple generic fonts (font: monospace,serif) cause unexpected variation of font-size
Initial conditions or steps before loading this testcase:
1- Go to Tools/Options.../Content tab/Fonts and colors section/Advanced.../
2- Set proportional to serif and then proportional default font-size to 16
3- Set fixed width default font-size to 10
4- Set minimal font-size to none

Note that CSS1 Test Suite: 5.2.2 font-family test page at
http://www.w3.org/Style/CSS/Test/CSS1/current/sec522.htm
is also using the same code for the first 2 sentences of this testcase.
Retest once bug 216456 lands, please.
Depends on: 216456
Whiteboard: [CSS1-5.2.2]
(In reply to comment #25)
> Retest once bug 216456 lands, please.

seems that this hasn't been resolved, considering bug 518746 was just reported as being the same.
Any updates on this? Do this change and/or lobby Webkit to change their default before Presto dies off? And maybe also change this as a forerunner to bug 468169 which might become relevant again once XP dies off?
See Also: → 1422598
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

This is legacy behavior that we're probably unlikely to change.

Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: