why does font size get interpreted differently in seamonkey {font} {ll}

VERIFIED FIXED in M14

Status

()

defect
P1
normal
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: chofmann, Assigned: pierre)

Tracking

Trunk
Other
Other
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] Becomes PDT- on 2/25, )

Reporter

Description

20 years ago
test url shows a smaller font size under netscape 4.x
browsers than under seamonkey. The difference
is big enought that when the content
gets put into a frame it causes frame scrolling to appear
when viewing the browser buster test pages.

do we need to live with this incompatiblity
or can we make the font size interpretation
be backward compatible with out loosing some
capability?

Updated

20 years ago
Assignee: troy → pierre
Component: Layout → Style System

Comment 1

20 years ago
This isn't really layout. Marking it as style system, although it could be a
difference in what the gfx code interprets sizes
Reporter

Comment 2

20 years ago
best to settle this early so not to much UI or 5.0
web content gets built with seamonkey in mind and
the we have to change it out from under the content
developers to be compatible.
Reporter

Comment 3

20 years ago
best to settle this early so not to much UI or 5.0
web content gets built with seamonkey in mind and
the we have to change it out from under the content
developers to be compatible.
Reporter

Comment 4

20 years ago
adding paulmac to cc list with 12/16 build
Todd might be interested in this...
Assignee

Comment 6

20 years ago
Warning: this is a dead-snake that resurfaced several times already.

The problem, I believe, exists on all platforms and is particularly accute on the
Mac. In a way I'm glad that someone rises the issue again because I and other Mac
users don't like the current solution but I'm also worried that debating over it
again and right now may last way into the next millenium and ruin our holidays. I
suggest we live with it for a couple of weeks, sit around a table with people
working on different platforms, drop any prejudices and calmly find a solution. I
collected below some related links and discussions, if you want to do a little
homework during your vacation.

First this bug is related to a couple of other ones:
  bug 18136: Fixing the font size mess
  bug 17926: Chrome on Mac is unusable at 72 dpi
  bug 5599:  Need a dialog to set the screen resolution

Most important, the very long thread started by our master Peter Linss:
  news://news.mozilla.org/37126623.E5B0BD50%40netscape.com

Then some threads initiated by myself who a bit awkwardly argumented in favor of
a compatibility with previous versions:
  news://news.mozilla.org/37267DB7.41F597FE%40netscape.com
  news://news.mozilla.org/3726A917.C566A59C%40netscape.com

Finally, an excellent proposition from our friend Todd Fahrner:
  http://style.verso.com/font_size_intervals/altintervals.html
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M20

Comment 7

20 years ago
*** Bug 22489 has been marked as a duplicate of this bug. ***
Reporter

Comment 8

20 years ago
m20? that would be an ugly milestone to fix this.
Assignee

Updated

20 years ago
Summary: [4.xp] why does font size get interpreted differently in seamonkey → {font}[4.xp]why does font size get interpreted differently in seamonkey
Target Milestone: M20 → M14
Assignee

Comment 9

20 years ago
M20 was just a convenient way for me to see the font-related bugs in my list.
Using the {font} tag in the summary line instead.
Assignee

Comment 10

20 years ago
Another related issue is being discussed on Bug 20789 ("Spaces between lines
bigger than legacy browsers'.") and on the n.p.m.layout newsgroup:
news://news.mozilla.org/387FFA01.DF09EAD1%40weirdness.com

Comment 11

20 years ago
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Assignee

Updated

20 years ago
Priority: P3 → P1
Assignee

Comment 12

20 years ago
*** Bug 25863 has been marked as a duplicate of this bug. ***
Assignee

Comment 13

20 years ago
*** Bug 25397 has been marked as a duplicate of this bug. ***
Assignee

Comment 14

20 years ago
*** Bug 26177 has been marked as a duplicate of this bug. ***
Reporter

Comment 15

20 years ago
are we going to try for beta1?  

Comment 16

20 years ago
Adding beta 1 to keyword list since browsing to common web pages
like http://my.netscape.com or http://www.news.com shows text
that is one or two font sizes too large. It's easy to see this when comparing
pages on seamonkey to 4.7.
Keywords: beta1
Assignee

Comment 17

20 years ago
Bug 25236 and bug 22967 will be closed as dup of this one.
The URLs they contain are:
    http://www.grack.com/visuals/r2.html
    http://www.msnbc.com

Marked this bug PDT+, as was bug 25236.
Whiteboard: [PDT+]
Assignee

Comment 18

20 years ago
*** Bug 25236 has been marked as a duplicate of this bug. ***
Assignee

Comment 19

20 years ago
*** Bug 22967 has been marked as a duplicate of this bug. ***
Assignee

Comment 21

20 years ago
*** Bug 24502 has been marked as a duplicate of this bug. ***

Updated

20 years ago
Summary: {font}[4.xp]why does font size get interpreted differently in seamonkey → {font}why does font size get interpreted differently in seamonkey
Assignee

Comment 22

20 years ago
*** Bug 26935 has been marked as a duplicate of this bug. ***
Assignee

Comment 23

20 years ago
Bug 26935, which was closed as dup of this one, contained interesting comments 
from erik on 2000-02-08 17:05. I disagree with rickg that the rounding code from 
Nav4 should be put back into Mozilla. We should use instead Todd Fahrner's paper 
(see my comments above dated from 1999-12-21 01:24).

Comment 24

20 years ago
I strongly agree with Pierre that we should not re-introduce the bad rounding
code into Mozilla. If we put it back in, we will not be able to legibly render
some documents that MSIE *can* render legibly. (I.e. font-size: 9px.)

I also think that making Mozilla compatible with MSIE is a wise decision. MSIE
is the market share leader, so there will be many documents out there that are
rendered properly by MSIE. We may even want to change the name of our Quirks
mode from "NavQuirks" to "Compatibility Mode".

I also agree with Pierre that Todd Fahrner's paper is a good one to read and
follow, but we should check MSIE's multipliers for HTML sizes 1-7, and make sure
they agree with Todd's. If they disagree, again, I prefer being compatible with
MSIE.

It may seem risky to change our multipliers for 1-7, but I believe we can do a
good job if we examine MSIE carefully. We may even be able to get the info from
them directly if we ask nicely. Or someone on the Net (Todd?) might even know
their multipliers. If we make our 1-7 multipliers the same as MSIE, the risk is
low, in my opinion.
Assignee

Comment 25

20 years ago
Todd is under NDA from a competitor and I wouldn't want to put him in an 
embarrassing position. We can take care of the implementation details.
What's the difference between this bug and bug 18136?
Here's the difference. Bug 21950 is a report that certain specific sites break 
because Mozilla displays their fonts larger than Nav4. Because some of these 
sites are Top 100 (News.com, My Netscape, etc.) this has been marked a PDT+ 
beta1 bug.

Bug 18136 is an enhancement request to implement Todd Fahrner's font system. 
Implementing that font system per se is not a beta1 requirement. (It's a 
very desirable enhancement request, which is something different.) HOWEVER, it 
is currently being asserted that implementing Todd Fahrner's font system will 
fix 21950, which *is* a beta1 bug.

So the situation should really be as follows: 
- 21950 is PDT+ beta1 (no change from current situation)
- 21950 depends on 18136 (now marking this)
- 18136 is not a beta1 bug for its own sake (clearing PDT+ for re-evaluation)
- HOWEVER, because 21950 is PDT+ beta1 and depends on 18136, 18136 inherits the 
21950 PDT+ beta1 status (noting this in comments for 18136, so PDT+ will likely 
be restored)

If we were to find a quick-and-dirty patch that fixed 21950 directly without 
implementing Todd Fahrner's system (18136), then the depends relationship would 
be eliminated and 18136 would lose its inherited PDT+ beta1 status.

Depends on: 18136
Assignee

Comment 28

20 years ago
Eric did not understand that Bug 18136 is not an enhancement request. It's an 
important feature of the layout engine. It allows XP compatibility, current IE 
compatibility on Mac and future compatibility on Windows, and standard 
compliance. It allows web designers to write-once-run-anywhere (IE/Moz, Mac/PC/
Unix). Another important point is that many major sites finally render correctly 
on the Mac.

It works but it needs minor tweaks in Text and Dropdown widgets. See bug 18136 
for more info.
The issue here is not a lack of understanding on my part but rather a difference 
of opinion, as reasonable people can of course disagree, regarding where we make 
the cutoff for beta1 and on what grounds. Further comments re: bug 18136 in that 
report. Thanks again to Pierre for his hard work on these bugs!
Summary: {font}why does font size get interpreted differently in seamonkey → why does font size get interpreted differently in seamonkey {font} {ll}
Depends on: 24005
Assignee

Comment 30

20 years ago
*** Bug 28802 has been marked as a duplicate of this bug. ***

Comment 31

20 years ago
per PDT, this bug becomes PDT- on 2/25
Whiteboard: [PDT+] → [PDT+] Becomes PDT- on 2/25

Comment 32

20 years ago
My problem was seamonkey display *smaller* fonts than Nav4.7 
Assignee

Comment 33

20 years ago
18136 is fixed, marking this one fixed too although we may still have some 
differences in the way font sizes are interpreted.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Assignee

Comment 34

20 years ago
*** Bug 27898 has been marked as a duplicate of this bug. ***

Comment 35

20 years ago
Howdens, please try it again with a new build. (A fix was checked in last
night.) If it still doesn't work, please tell us which platform you're on.

Comment 36

20 years ago
I have upgraded to 2000022408 and am still seeing the same font size problem:

Seamonkey displays smaller text than NSv4.7

URLs www.ibm.com, www.gartner.com

I am running on Windows NTv4 SP3

Comment 37

20 years ago
Howdens, what are your fonts set to in Nav4? (Edit | Prefs | Appearance | Fonts)
Also, what is your Windows font setting set to? Start | Settings | Control Panel
| Display | Settings | Font Size. Have you set font sizes in Seamonkey?
Everyone, let's start opening separate bug reports now on each separate issue we 
discover, to preserve the 1 bug report = 1 issue principle. Thanks for all your 
testing and reporting!

Comment 39

20 years ago
I am using the default NS NAV fonts
Western | Times New Roman 12 | Courier New 10 | User specified fonts, includind 
Dynamic fonts

In Windows NT display settings I have "small fonts" selected - that would be the 
same for both NS NAV and Seamonkey

In Seamonkey I have the following default settings font settings

X-western | Times New Roman 12 | Courier New 12
Use fonts chosen by page
96 dpi





Comment 40

20 years ago
Seamonkey's defaults are Times/16px and Courier/13px now. Note that the unit is
px (pixels), which is different from Nav4, which used points (pt).

Comment 41

20 years ago
Verified in the Feb 29th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.