Last Comment Bug 175415 - multiple generic fonts (font: monospace,serif) cause unexpected variation of font-size
: multiple generic fonts (font: monospace,serif) cause unexpected variation of ...
Status: NEW
[CSS1-5.2.2]
: css1, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P4 normal with 11 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://fgmusic.org/~fgasper/mass_pts
: 205537 518746 (view as bug list)
Depends on: 216456
Blocks: 205537
  Show dependency treegraph
 
Reported: 2002-10-18 19:10 PDT by Felipe
Modified: 2013-03-10 14:54 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase. Must set different sizes for "normal" and "fixed-width" text to test (237 bytes, text/html)
2002-10-18 23:38 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details
Complete, self-explanatory testcase (1.80 KB, text/html)
2007-07-14 13:32 PDT, Gérard Talbot
no flags Details

Description Felipe 2002-10-18 19:10:59 PDT
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.
Comment 1 Christopher Hoess (gone) 2002-10-18 19:29:50 PDT
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?
Comment 2 David Baron :dbaron: ⌚️UTC-10 2002-10-18 20:25:07 PDT
I don't see a problem.  If there is one, it seems like it would be in the
windows font code.  ->shanjian
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2002-10-18 23:37:42 PDT
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?
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2002-10-18 23:38:26 PDT
Created attachment 103436 [details]
testcase.  Must set different sizes for "normal" and "fixed-width" text to test
Comment 5 Hixie (not reading bugmail) 2002-10-19 05:31:24 PDT
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.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2002-10-19 09:26:59 PDT
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.
Comment 7 Hixie (not reading bugmail) 2002-10-19 16:42:07 PDT
That should definitely change then; 'font-family: monospace' shouldn't cause any
change of 'font-size' and should not affect 'font-size-adjust'.
Comment 8 rbs 2002-10-20 14:42:10 PDT
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.
Comment 9 rbs 2002-10-20 14:54:59 PDT
<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).
Comment 10 Hixie (not reading bugmail) 2002-10-20 18:18:15 PDT
Yet another reason not to have any sort of magic here.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2002-10-21 07:25:24 PDT
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?
Comment 12 Hixie (not reading bugmail) 2002-10-21 13:48:55 PDT
Hey, I have a radical idea here, why don't we do what the spec says and only
have one font size?
Comment 13 rbs 2002-10-21 15:36:55 PDT
> 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.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2002-10-21 16:10:06 PDT
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?
Comment 15 rbs 2002-10-21 16:22:26 PDT
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>
Comment 16 Hixie (not reading bugmail) 2002-10-22 08:58:11 PDT
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.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2002-10-22 09:09:19 PDT
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...
Comment 18 Hixie (not reading bugmail) 2002-10-22 09:48:02 PDT
font-size-adjust inherits.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2002-10-22 09:54:29 PDT
Ah.  I see... I just re-read that part of the spec, and that _should_ indeed
work....
Comment 20 rbs 2002-10-22 15:22:57 PDT
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)
Comment 21 Hixie (not reading bugmail) 2003-02-22 10:27:49 PST
I've been using that rule for several months now with no ill effects.
Comment 22 Gérard Talbot 2007-07-14 12:03:05 PDT
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.
Comment 23 Gérard Talbot 2007-07-14 12:26:46 PDT
*** Bug 205537 has been marked as a duplicate of this bug. ***
Comment 24 Gérard Talbot 2007-07-14 13:32:07 PDT
Created attachment 272334 [details]
Complete, self-explanatory testcase

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.
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2007-07-14 13:39:54 PDT
Retest once bug 216456 lands, please.
Comment 26 John P Baker 2009-09-25 01:31:37 PDT
*** Bug 518746 has been marked as a duplicate of this bug. ***
Comment 27 Abel Braaksma 2009-09-25 10:47:16 PDT
(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.
Comment 28 [Baboo] 2013-03-10 14:54:58 PDT
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?

Note You need to log in before you can comment on or make changes to this bug.