bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Linux doesn't calc font sizes correctly



Core Graveyard
16 years ago
4 years ago


(Reporter: rods (gone), Unassigned)




Firefox Tracking Flags

(Not tracked)



(7 attachments, 2 obsolete attachments)



16 years ago

Comment 1

16 years ago
The font size for Linux fonts are not calculated correctly according to dbaron
in Bug 153080 once the final patch there is applied.

See this screen shot:

Although dbaron seems to feel that the 12pt is too small, one must remember that
the page is being scaled. I think the font with the problem is "medium".

Look at the various fonts and how large they are compared to each other in the
test http://bugzilla.mozilla.org/attachment.cgi?id=92430&action=view

And then look at the screen hot again. The 12pt and 16px fonts look correct but
the medium font looks too small.
Blocks: 153080
Keywords: nsbeta1
This is blocking 153080 which is nsbeta1+.


16 years ago
OS: Windows 2000 → Linux


16 years ago
Priority: -- → P2

Comment 3

16 years ago
I'm not sure if this is the same issue but quite often I feel I have to 
increase the font size (by pressing Ctrl +) to get the view of a page that one 
would normally see in IE. "Normal" fonts in Mozilla seem to be smaller than in 
IE, 120% seems about right. Hope it'll get fixed. Thanks.

Comment 4

16 years ago
Attaching test case
Keywords: testcase

Comment 5

16 years ago
Created attachment 109458 [details]
Test Case

Comment 6

16 years ago
When I view the attachment I see:

  The image "http://bugzilla.mozilla.org/attachment.cgi?id=109458&action=view"
cannot be displayed, because it contains errors.

Is this expected?

Comment 7

16 years ago
Created attachment 109626 [details]
Another testcase

I get the same error as in comment 6, so I built my own testcase. Looking at it
in Mandrake Linux 9.0 KDE 3 1024x768 and 2002121708 trunk, default font set to
16px monotype-arial-iso8859-1 (which I think is arial.ttf from mswbfnts) 120
DPI, I find it difficult to distinguish from OS/2 2002121612 trunk with arial
(arial.ttf from mswbfnts) 16px 1024x768 120 DPI.

Comment 8

16 years ago
Created attachment 109857 [details]
Reduced test case
Attachment #109458 - Attachment is obsolete: true

Comment 9

16 years ago
Except in variety, doesn't look like a reduction to me, but more important, I'm
seeing a bizarre result from the comment 8 testcase. Using trunks 2002121912 for
OS/2, 2002122004 for W98, & 2002122008 for Linux, all at 1024 x 768 with prefs
set to Arial 16px, Linux & OS/2 are essentially indistiguishable, with a second
line that does not appear as expected from its description or lack thereof
(looks like 12pt), while everything else seems to match its size description
(can't say about size in pc, since I have no idea what that is). In contrast,
everything except the 5ex paragraphs is displayed by W98 at 16px. Linux and OS/2
render both 5ex paragraphs the same, while W98 renders the second 5ex paragraph
considerably larger.

adding mkaply cc for possible comment

Comment 10

16 years ago
Is an argument trying to be made here that in the reduced testcase, all the
fonts should appear the same size?

This is simply not correct.

In a default situation perhaps, but some of the units are absolute and others
are relative.

I guess I don't understand what the argument is here.

12 point is 12 point. And if when Mozilla displays a 12 point it is the same as
say another editor on the same machine displaying 12 point, then it would be a
correct 12 point.

You can't use points to determine if fonts are being displayed correctly,
because DPI changes the points.

If have to set things to pixels and then actually measure the fonts to make sure
they are using the right number of pixels...

Comment 11

16 years ago
Created attachment 109901 [details]
Comment 8 testcase with blank lines removed & other minor clarifications

Comment 12

16 years ago
Created attachment 109902 [details]
testcase d reduced

3 screenshots to follow

Comment 13

16 years ago
Created attachment 109905 [details]
Linux 96DPI 1024x768 resolution screenshot of attachment 109902 [details]

Comment 14

16 years ago
Created attachment 109906 [details]
OS/2 96DPI 1024x768 resolution screenshot of attachment 109902 [details]

Comment 15

16 years ago
Created attachment 109907 [details]
W98 96DPI 1024x768 resolution screenshot of attachment 109902 [details]

With Linux, OS/2 & W98 all running 1024x768, 96DPI, 16px Arial default, I can
see no difference in the c & d testcases across the OS's except for the last
paragraph, which is larger in W98.

While the 109902 text rendering of Linux and OS/2 are close match to each
other, they obviously differ from W98. Which is right and which is wrong I
don't know, but I should think smaller followed by larger would put you back
where you started.

Comment 16

16 years ago
s/last paragraph, which is/last paragraphs, which are/

Comment 17

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 18

13 years ago
Created attachment 194331 [details]
WinXP 96DPI 1024x768 resolution screenshot of attachment 109902 [details] in 2005083006 trunk

Current trunk on W98 is similar, rendering the 2nd two paragraphs the same
Attachment #109907 - Attachment is obsolete: true

Comment 19

11 years ago
is this helped/fixed by bug 177805?


11 years ago
Assignee: pavlov → nobody
QA Contact: chrispetersen → general


9 years ago
Product: Core → Core Graveyard
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.