Closed Bug 21950 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect, P1)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
Other
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: chofmann, Assigned: pierre)

References

(
URL
)

Details

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

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?
Assignee: troy → pierre
Component: Layout → Style System
This isn't really layout. Marking it as style system, although it could be a difference in what the gfx code interprets sizes
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.
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.
adding paulmac to cc list with 12/16 build
Todd might be interested in this...
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
Status: NEW → ASSIGNED
Target Milestone: M20
*** Bug 22489 has been marked as a duplicate of this bug. ***
m20? that would be an ugly milestone to fix this.
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
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.
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
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Priority: P3 → P1
*** Bug 25863 has been marked as a duplicate of this bug. ***
*** Bug 25397 has been marked as a duplicate of this bug. ***
*** Bug 26177 has been marked as a duplicate of this bug. ***
are we going to try for beta1?
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
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+]
*** Bug 25236 has been marked as a duplicate of this bug. ***
*** Bug 22967 has been marked as a duplicate of this bug. ***
*** Bug 24502 has been marked as a duplicate of this bug. ***
Summary: {font}[4.xp]why does font size get interpreted differently in seamonkey → {font}why does font size get interpreted differently in seamonkey
*** Bug 26935 has been marked as a duplicate of this bug. ***
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).
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.
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
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
*** Bug 28802 has been marked as a duplicate of this bug. ***
per PDT, this bug becomes PDT- on 2/25
Whiteboard: [PDT+] → [PDT+] Becomes PDT- on 2/25
My problem was seamonkey display *smaller* fonts than Nav4.7
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
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 27898 has been marked as a duplicate of this bug. ***
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.
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
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!
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
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).
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.