Closed Bug 396774 Opened 18 years ago Closed 18 years ago

gecko renders monospaced fonts (such as Courier New, or Lucida Console) in <pre> tags WAY TOO BIG

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: nelson, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(6 files, 1 obsolete file)

typical bonsai diff page that appears in a HUGE font in 2.0a1pre
97.45 KB, text/html
Details
revised test case with <pre> added
85 bytes, text/html
Details
first attachment above, as seen with SM 1.5a
7.62 KB, image/gif
Details
first attachment above, as seen with SM 2.0a1
9.05 KB, image/gif
Details
same as attachment 283384 except with all occurrences of <FONT FACE='Lucida Console' SIZE=-1> replaced by <FONT SIZE=-1>
82.08 KB, text/html
Details
screenshot of portion of comment 35 URL
174.49 KB, image/jpeg
Details
The side-by-side diffs shown by bonsai's cvsview2 tool should be more like the side-by-side diffs shown by bugzilla's patch diff tool. The font should be small enough that I can see both sides, (without the patch and with the patch) side by side in the same window, without any horizontal scroll bar. bugzilla's side-by-side diff pages do that quite nicely. bonsai's side-by-side diff pages use such a large font that one cannot see both the before and after sides on the same screen at the same time. A horizontal scroll bar is always necessary. This makes bonsai's pages pretty useless for after-the-fact code reviewing purposes. When I view diffs (patches) using bugzilla's patch diff tool, I get a page showing the before and after columns, side by side. when the patched source is 80 columns wide or less, I have no trouble seeing all the text in both sides (the before and after sides) side by side in the same window, without any horizontal scroll bars. Can't do that with bonsai. Here's a concrete example. Here's a side-by-side diff, as shown by both bugzilla and bonsai, of the same patch to the same file. https://bugzilla.mozilla.org/attachment.cgi?id=281279&action=diff#mozilla/security/nss/lib/libpkix/pkix/top/pkix_lifecycle.c_sec1 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/security/nss/lib/libpkix/pkix/top&command=DIFF&root=/cvsroot&file=pkix_lifecycle.c&rev1=1.4&rev2=1.5
I find that if I take the source to the bonsai page cited above, and edit it, changing all the SIZE=-1 strings to SIZE=-3 then the results are usable. I'm not suggesting that is the right solution, but it would be much better than what we get now.
This problem appears to be the fault of the browser, not bonsai, so I am changing this bug to be a browser bug. I downloaded a sample page from bonsai that exhibits the too-large font problem, and saved it in a local file, and viewed that file in both SeaMonkey 2.0a1pre, and in SeaMonkey 1.5a (the last build with that designation, which is now several months old). In SM 1.5a, the file appears as expected with a font of reasonable size. In SM 2.0a1pre, the same file appears with the much-larger (too large) font. The file I downloaded was http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/security/nss/cmd/certutil&command=DIFF&root=/cvsroot&file=certext.c&rev1=1.4&rev2=1.5
Assignee: tara → general
Component: Bonsai → General
Product: Webtools → Mozilla Application Suite
QA Contact: bonsai → general
Summary: bonsai cvsview2 diffs use a WAY TOO BIG font → SM 2.0a1 displays bonsai cvsview2 diff pages with a WAY TOO BIG font
Target Milestone: --- → seamonkey2.0alpha
Here's a page that demonstrates the difference when viewed with the two versions of the browser. Any bonsai diff page should do, this is just one example.
I tested with different profiles. Same behavior. 1.5a displays the pages with reasonable font sizes. 2.0a1 displays with a LARGE font. This is on WinXP.
OS: All → Windows XP
Hardware: All → PC
Flags: blocking-seamonkey2.0a1?
Keywords: regression
So I made a reduced testcase, which is basically <font face=monospace size=-1>X</font><font face="Courier New" size=-1>X</font> Unfortunately the Xs appear at difference sizes. Someone somewhere has forgotton that "Courier New" (or "Lucida Console", or whatever) is a monospace font, and therefore the monospace font size pref should apply to it.
Flags: blocking-seamonkey2.0a1?
Strange, I was sure I'd changed the product...
Assignee: general → nobody
Component: General → Layout: Fonts and Text
Product: Mozilla Application Suite → Core
QA Contact: general → layout.fonts-and-text
Target Milestone: seamonkey2.0alpha → ---
Flags: blocking1.9?
Attached file Neil's reduced test case (obsolete) —
Thanks for the test case, Neil.
Keywords: testcase
Neil, I tried your test case with SM 1.5a, which displays the bonsai page with a reasonably sized font (IOW, which doesn't exhibit this bug), and the two X's displayed with different font sizes in 1.5a also. So, I'm not entirely sure that your reduced test case (which I attached above) actually gets to the heart of this issue.
Ah, interesting... I over-reduced my test case, you also need the <pre> to demonstrate the difference.
What Gecko versions do all these SeaMonkey versions correspond to?
The last SeaMonkey 1.5a would have been 1.9a5pre (end of May 2007).
With this test case, SM 2.0a1 Gecko/2007100703 sees two X's of different sizes SM 1.5a Gecko/20070528 sees two X's of the same size
Attachment #285495 - Attachment is obsolete: true
I'm attempting to revise the bug summary to describe the problem, as I now understand it.
Summary: SM 2.0a1 displays bonsai cvsview2 diff pages with a WAY TOO BIG font → gecko renders monospaced fonts in <pre> tags WAY TOO BIG
In the font preferences, what are your monospace and non-monospace font size prefs? (I'd love to get rid of the difference, but it's not happening for 1.9.)
David, you asked: > what are your monospace and non-monospace font size prefs? For which language? (Guessing: Western) I have a feeling there's a lot of info you need here, including prefs for different languages, and also prefered/default character set encodings. (yes ?) Curious discovery: The first time I go look at the Western fonts in the prefs dialog, I see one set of values. If I then click on another language, and then click western again, I see a different set of values. :-( Closing the prefs dialog and reopening it restores the initial set. The initial values are: Fonts for: [ Western ] Typeface Size (pixels) Proportional: [ Serif ] [ 16 ] Serif: [ Times New Roman ] Sans-serif: [ Arial ] Cursive: [ Comic Sans MS ] Fantasy: [ SimSun ] Monospace: [ Courier New ] [ 13 ] Minimum font size: [ None ] [x] Allow documents to use other fonts After visiting "Other Languages" and returning to "Western", I see Fonts for: [ Western ] Typeface Size (pixels) Proportional: [ Serif ] [ 16 ] Serif: [ ] Sans-serif: [ ] Cursive: [ ] Fantasy: [ SimSun ] Monospace: [ ] [ 13 ] Minimum font size: [ None ] [x] Allow documents to use other fonts My default web page character encoding is UTF-8.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Robert, Please say why this doesn't qualify as a blocker. It's clearly a regression from 2.0, and it makes the diffs from bonsai.mozilla.org basically unreadable to developers. Courier New is a (the?) standard monospace font, so it's not like this is some unusual edge case. (is it?)
I was the one who suggested wanted rather than blocking, though that was a quick judgment that I'd be willing to reconsider given more information. My main rationale is that I don't think this problem is very widespread, and given that there's not yet enough information in the bug for me to reproduce the problem, I'm not sure how one would go about fixing it. I'd think we'd have seen significantly more complaints if it were. Some questions: * does it happen in a default configuration of SeaMonkey or Firefox? (i.e., a newly-created profile) * is it the result of specific preferences set by the UI -- and, if so, by the UI in both SeaMonkey and Firefox? * what platforms does it occur on? * What exactly counts as "way too big" to you? A screenshot might help. It might be useful to have all of the font-related preferences from the prefs.js in your profile directory as an attachment to the bug.
David, thanks for the reply. - It happens on windows. - It happens in brand new profiles. - it is demonstrated by viewing the first attachment to this bug, first in browsers that are older (like SM trunk 1.5a, mid May 2007 or older) then with latest SM 2.0a1 trunk. - I don't know what you're asking for exactly regarding "specific preferences set by the UI", but I'll be happy to answer any somewhat more specific questions you might care to ask. - please give me a hint about the pref names to grab for font prefs. But remember that these occur in brand new profiles with default settings. With SM prior to end of May 2007, one could look at the diffs from bonsai on a 1280x1024 monitor, and see two 80-column wide (or more) views, (without and with the patch) side by side with no horizontal scroll bar. With new SM, the size of the font is (I would say) ~50% bigger, such that in the same 1280x1024 window, one can only see one 80-column wide "before" patch image,and about half of the other 80-column wide "after" image, or vice versa. Also, if you look at the second attachment to this bug, with 1.5, you see two X characters of the same size, but in later browsers, you see two X's of very different size. This is a microcosm of the bigger issue. I will attach two images, both are shots of the image seen when viewing the first attachment to this bug, with SM 1.5a (mid May) and with SM 2.0a1 (early October). Each image is ~1280 pixels wide, but only 100-200 pixels tall. You can see the difference.
(I hope I didn't switch these two images)
Given that it happens for you in clean profiles, ignore the questions about prefs UI and Firefox/SeaMonkey differences.
Do you have a more accurate regression date?
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Using 20px default monospace in both 2.0.0.13 and 2008041204 Minefield on KDE3.5.5 the PRE text in the first attachment in FF3 is noticeably bigger than in FF2. -> ALL Regression is between 2007072304 Minefield (OK) and 2007072404 Minefield (not OK)
OS: Windows XP → All
2007072319 Minefield is also OK. Bonsai regression window http://tinyurl.com/64fvtb Bug 383979 fix by David Baron is regression candidate.
Of the two characters in the testcase, which is sensitive to the monospace font size pref and which is sensitive to the regular font size pref? (Both before and after the regression?)
To answer my own question, the first character in attachment 285495 [details] is sized based on the monospace font size pref, and the second character is sized based on the non-monospace font size pref (which is the expected result when the implied generic font is serif/sans-serif). I see this in both 2007-07-20-04-trunk and 2007-07-25-04-trunk. (I want to get rid of having the separate font size prefs for monospace and non-monospace now that we have the font-size-adjust infrastructure, but that's for a later release.)
Then again, I'm having trouble seeing any differences between those two builds.
Er, sorry, I was using the wrong testcase. What's going on in attachment 285529 [details] is that before that patch, we were using the monospace font size pref for both, but after the patch, we use the non-monospace font size pref for the latter. On Linux, I don't even have courier new, so we also change, in that case, to using the default non-monospace font. I think these changes are correct. It was a bug that when there was an author-specified font-family value on the font element, the resulting font was still influenced by a font inherited from an ancestor. (My memory, although a little rough by now, is that that was the case *some* of the time before the patch, depending on what other properties were specified, and now we're consistent both internally and with what the spec says we should do. But I could be wrong about the prior internal inconsistency. I remember fixing a few such cases a while back, but I'm not sure if it was the patch in question.)
Status: NEW → RESOLVED
Closed: 18 years ago
Component: Layout: Fonts and Text → Style System (CSS)
Resolution: --- → INVALID
Safari 3.1 on Win, which also has separate font size pref for monospace, using first testcase matches sizes in trunk rather than FF2, which would seem to confirm comment 28 and resolution invalid. Original component for this was Bonsai. If it were changed back it should still be valid as a need/desire to update Bonsai CSS to produce FF2-style font sizing. FWIW, Safari line height in first testcase is much smaller than trunk, showing about 11 more lines than trunk in a 1020px tall window.
I can accept that font size prefs for "monospace" and "Courier" should be different. But the font size pref for "Courier" is WAY too big. Given that the html calls for size="-1", the size should be smaller than the default. Evidently the default size for courier is HUGE. I surely don't want the default size for courier to be bigger than 10 or 12 pt, and it's MUCH larger than that.
I see the subject URL now differs from the first testcase in that all instances of <FONT FACE='Lucida Console' SIZE=-1> have been removed. In order to get the pre-bug 383979 behavior back, bonsai could be changed in the manner of this attachment. When I view my local copy of this in both FF2 and trunk, the font sizes are the same, though line-height is larger in trunk by about 7 lines per 1020px tall window. Anyone who wants the old text sizes without waiting for a bonsai configuration change can add the following to userContent.css in their Gecko profile's chrome directory: @-moz-document domain(bonsai.mozilla.org) { td>pre {font-size: smaller !important;} }
Felix, I'm looking for a solution that applies to ALL pages that use Courier or Lucida inside <PRE> tags, not only for bonsai.
My complaint is that these fonts are rendered way too big. It may be that there was a bug that cause them to be rendered in the same size as the "monospace" font, and that that has been fixed. That doesn't change the fact that Courier New and Lucida Console are rendered in ~16 pt type in PRE tags.
Summary: gecko renders monospaced fonts in <pre> tags WAY TOO BIG → gecko renders monospaced fonts (such as Courier New, or Lucida Console) in <pre> tags WAY TOO BIG
In some sense this is a bug in the page, since it's not giving appropriate fallback for the font that indicates that it's monospace. It would also be fixed by bug 380915, which would adjust the font sizes based on the x-heights of the fonts rather than just having two fixed preferences.
Current bonsai diff pages do not use <FONT> elements. Except for one CSS rule, 'pre {margin: 0;}', they rely entirely on browser default styles, tables, and <PRE> elements for layout, text size, and font-family. Nelson, study http://fm.no-ip.com/auth/Font/fonts-face-samplesM.html and you should see that: 1-Courier New and Lucida Console render the same size as most other monospace fonts 2-PRE, TT, CODE, KBD, SAMP & TEXTAREA all render using your default monospace family and size
Felix, thanks for the pointer to that font face samples page. After studying it, I conclude that Courier New and Lucida console do NOT render the same size as most other monospace fonts of the same point size. Specifically, those two character sets render with quite different widths. (Those two type faces do render at the same size as each other, but not the same sizes as (say) Courier (without the New)). I could attach a set of .gifs containing screen captures from that page. Perhaps this relates to another issue I often see, which is that tabs do not appear to expand to a multiple of 8 spaces in monospaced font displays. This makes reading code in a browser window painful. I really hate to say it, but IE7 does a much better job of that on my system.
On today's trunk on WinXP, shows Courier New & Lucida Console render 9pt, 10pt, 11pt & 12pt @ 96DPI at same character widths as Andale Mono, DejaVu Sans Mono, & Liberation Mono, and also PRE rendering at 10pt. It also shows Courier (a bitmap font) 9pt, 10pt & 11pt rendering at an identical width matching 10pt of all the other shown monospace fonts except Consolas.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: