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)

defect

Tracking

()

People

(Reporter: felipe, Unassigned)

References

()

Details

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

Attachments

(2 files)

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

Created:
Updated:
Size: