In Mozilla, I have to set a default font size of "16" to get the same Times New Roman font size that I get in every other app (Word, Notepad, Netscape 4.x) by setting a font size of "12". Why does Mozilla use a different unit than other Windows XP apps? This confused me, and I would expect it to confuse anyone used to Word's units (which it claims are points). I'm running at 800x600 resolution and my DPI setting (control panel, display, settings, advanced) is "Normal size (96 DPI)".
We use 'px' and this is _very_ clearly labeled in the dialog in question. (And yes, at 96dpi, 16px == 1/6 inch == 12pt.) One reason to use px instead of pt is that this way changing the screen resolution will actually change the size of the text... (since Windows manages to divorce its concept of DPI from the actual DPI that you're running for some reason)...
Jesse, was it you who changed the summary on bug 181438 without commenting in that bug? You can see some related discussion on this in WONTFIX bug 51984. I've been spending a lot of time lately coming up with various ways to show the interplay between pixels, points, screen resolution, etc. Some of this I've already put up at http://members.ij.net/mrmazda/auth/auth.html. Many people think that 13px is the same thing as 10pt, but that only applies at 96 DPI. At 120 DPI, appropriate for higher resolutions than 800x600, 16px is 10pt. At 1024x768, the default 16px setting is exactly what it should be, regardless of DPI, and it matches IE6 at medium at that resolution using the default 96 DPI. People with lower resolutions need to adjust to smaller px values, while those with higher, the converse. At 800x600, 13px comes very close in actual size to 16px at 1024x768.
The units are labelled in Mozilla, but not in the other programs, so I think it's reasonable that I got confused.
We can't very well fix other programs...
But we could switch to the more common unit...
Feel free to find the extensive discussion to that effect that's happened in other bugs and read it.
If I had been able to find that discussion, I would have linked to it when I filed this bug. Do you know how to find it?
Pixels was made the only choice after bug 28899. Prior to that point, there was a choice. I can't find the relevant discussion for that, though, and I know there has been significant discussion of this issue. I suspect it may have been on n.p.m.layout, involving Todd Fahrner, Erik van der Poel, and perhaps Braden McDaniel. The only thread I could find is: http://groups.google.com/groups?selm=7950ok%24nen1%40secnews.netscape.com (Note that style.verso.com is now style.cleverchimp.com.) but you might want to start reading the thread around: http://groups.google.com/groups?selm=7978q3%24quu2%40secnews.netscape.com
i'd vote for consistency w/ other apps :). too bad it doesn't help my laptop/desktop problems :|.
Maybe its high time to evangelize other apps. Points weren't ever good for computer displays, and have gotten worse as monitor sizes, resolutions, and DPI values have increased. A point is supposed to be 1/72", which is mostly only the case for very small computer displays when the monitor is connected to a Mac. Wise is Mozilla's use of pixels instead of points in the prefs panel.
This is not just WinXP. X servers think in points (actually decipoints). The standard X bitmap fonts are well-ordered in points but not in pixels. Mozilla jumps through a number of hoops to deal with that. Also, what about CSS2 @font-face? It thinks in points as well. Mozilla has just gone the wrong way on this.
> Also, what about CSS2 @font-face? It thinks in points as well. It thinks in points just as much as it thinks in inches, picas, em, or px... (as in, you can use any length units you want).
What I see in the docs for @font-face is: 'font-size' (Descriptor) Value: all | <length> [, <length>]* Initial: all Media: visual This is the descriptor for the sizes provided by this font. Only absolute length units are permitted, in contrast to the 'font-size' property, which allows both relative and absolute lengths and sizes. A comma-separated list of absolute lengths is permitted. so em, px, et. al. are disallowed.
Ah, you're right. Good thing this is gone from CSS2.1; I'll have to make sure it's not reinstated in the form it's in... (since CSS px make a lot more sense as a font size unit than points do, in almost all applications I can think of).
So nice of W3C to hide css2.1 so you have to know it exists before you can find it. :-( I sure hope there's a extremely clear definition of a CSS px. In any event, CSS isn't an OS. Mozilla has to talk to the OS and should probably expose the OS metrics so as not to confuse the user.
Integer point values are more granular than pixels when DPI exceeds 72. Within the 9-16 pixel range are 8 discrete integer sizes. Within the same 9-16 pixel range, there are only 8 discrete point sizes available if the DPI is 72. For those using higher DPI settings suitable for larger monitors and higher resolutions, including the current 96 DPI standard for Windows, the discrete options are limited unless the prefs menu is populated with fractional values. At 96 DPI, only 6 integer point values are available. At 120 DPI, only 5 integer point values are available. Higher DPI settings will become more appropriate as higher resolution options increase, further limiting choice where only point values are offered.
Hope you don't mind a user perspective here... The BIG difference between pixels and points from a user perspective is that in trying to adjust the size of all the page being viewed, points is much better. Why? Because if mozilla (I am using Linux Mozilla for the purposes of discussion) assumes all fonts requested are in points not pixels, then if I want *all* of the fonts to look bigger, I can just change the DPI of my display in settins, and everything scales (well it should anyway!). How do I do this with pixel based font sizing? Not possible. I miss Galeon's "zoom the page" feature... everything scales up just like viewing a document in a word processor. That is what I want, now that I have to put up with microscopic (albeit high quality) fonts on my screen with mozilla and XFT (which should be better not worse!). This is enough to cause me to drop mozilla as my linux browser though I really really dont want to, I use mozilla 1.3 and am happy under Windows 2000. Thanks for listening- I hope you can understand the frustration of a normal user.
If the xft build is outputting microscopic fonts, that's a bug in the xft build, no? (And are these fonts in pages or UI? The xft builds default to a 10_pt_ UI font for some reason.)
Well, I didn't mind until I got a new monitor which goes to 1600x1200. Simply changing the X server DPI to 132DPI (calculated using the monitor physical size in the manual) made all the fonts everywhere the same size as before. However, I got confused by Mozilla's font size settings (most important of them, the minimum font size) until I noticed they were in pixels (I'd never expected it, since every other program uses points). The units would be clearer if they were next to the dropdowns instead of in the heading, but it's still annoying to have to calculate the values instead of simply specifying them in points directly. Why does Mozilla have to be the only application which specifies the font sizes in pixels? (And if the cause is a Windows bug, shouldn't the kludge be used only on Windows?)
Besides answers given in previous comments, pixels give the user more control, and more control to the user in the browser is a high demand feature class. :-) Some people find it more annoying to find the pref size they want is unavailable. Open your DPI's link on http://members.ij.net/mrmazda/auth/pt2px.html for a comparison applicable to your own system that demonstrates comment 16. The ultimate solution for the prefs panel is bug 33340.
Another reason for using points instead of pixels: Suppose you are running Mozilla remotely, from a number of different X servers with different DPI settings. Or that your $HOME is shared, and you use it in different computers with different DPI settings. In both situations, if Mozilla uses points, the font size stays the same; but since it uses pixels, you have to reconfigure every time you change your DPI.
Most people change their DPI once or less. You have the option to force Mozilla to use a particular DPI via user.js or about:config: user_pref("browser.display.screen_resolution", 100);
So if I use Mozilla on my home machine which is a 120-dpi flat-panel and I also use it on a lab machine which is using a 72-dpi display I should force them both to some random third dpi? Sorry, but that seems silly.
But which is more relevant to the readability of the font? On a lower-resolution display, you're probably going to want larger font sizes because otherwise poor rasterization would interfere with legibility.
I'm just pointing out that comment 22 does not address the core issues under discussion....
(In reply to comment #23) > So if I use Mozilla on my home machine which is a 120-dpi flat-panel and I also > use it on a lab machine which is using a 72-dpi display I should force them both > to some random third dpi? Sorry, but that seems silly. In the unusual circumstance described, you could/should run Mozilla from a script that changes the DPI via user.js before starting Mozilla, or use different profiles preset with the proper DPI for the display used. I don't think the argument made in the comment I was replying to is justification for reducing user control. Points are for paper, not computer displays, not since the growth of high resolution and high DPI anyway. At high DPI, points are simply too coarse an adjustment for good control, unless fractional sizes are offered in the prefs UI. The best thing would be to not only fix bug 33340, but as of a part of it to include a slider for the adjusting, and the removal during selection of any reference to what size is shown, letting the eyes decide without the help of any numbers what size is the best.
I think with large monitors and the DPI setting properly adjusted, the point unit is not too coarse, bacause it's the same as in any other resolution, 1/72 of an inch. It does not matter to me if an inch in my monitor is 2000 or 20 pixels, All I care is to have readable fonts and I can use points like I do in word processors and everywhere else. IF there is a DPI setting it is there for the sake of translating point units to pixels in a given monitor and resolution config. So I think the default unit should be points, not pixels. Why should I bother setting the dpi if all fonts are in pixels? Also I think the default stylesheet (when there's no stylesheet setting for font sizes) should specify points and not pixels. The point unit is more stable when switching screen resolution. If well implemented you allways get the same size for fonts after setting the new DPI. Maybe this is not the right bug, maybe I want a RFE to change the default unit from px to pt.
1/72" per point on screen media is a fiction. Adjusting to an actual DPI equating to 1/72" per point creates as many problems as it solves, if it is possible at all, which may not be the case on any given system. "Here are a few basic rules that one should follow in order to create Web pages that are easy (enough) to read, using CSS's font properties. * Do not specify the font-size in pt..." http://www.w3.org/2003/07/30-font-size "Points are provided as part of the CSS specification so that you can set up an alternative stylesheet for those who would like to print out your page rather than read it on screen." http://www.scotconnect.com/webtypography/points.php Page designers are told to not use points for screen media. A screen media reader shouldn't use points either. Review comment 8 & its links if you missed them.
Browsing mozillazine I read this: --- "I have the same problem. Just moved to a new system with a high-res display (2046x1535) ,The minimum size font is 16 pixels, and the DPI is 139. I have to press "Control-+" twice to even SEE this page I'm typing in. And I have to do this to each and every page I visit. Yes, I have this problem on this page and the Firefox home page. Sometimes I go to a page, and the pop-up choices (e.g. specify US State) has a HUGE font, but the rest of the page is unreadable. Fedora Core 1" --- It's here http://forums.mozillazine.org/viewtopic.php?t=67192&highlight=dpi By using pixels either in the style sheet or in the browser default font size you have to address the problem regarding the physical length of the pixel in a given display. If mozilla provides a DPI setting I believe it has that purpose exactly so why not make the user set the DPI to his real value and base fonts on that in any unit you prefer: % of the monitor length, cm, inches, mm. I think the current setting works because most monitors now have about 85-100 dpi so 16 pixels look fairly readable, but it's not a general solution. Maybe it's the best solution available and we only need to tell users with huge monitors to adjust things, but I still believe the general solution is to set default size to a physical amount of screen space. If mozilla or the platform can ensure a point to be 1/72 or a inch then pt is a suitable unit. In the same page discouraging using point for web developers it discourages using pixels. See here: http://www.scotconnect.com/webtypography/pixels.php The screen reader should use a physical measure constant in every monitor and every resolution. Let's say the default fonts should allways be 5 millimiters. I suggested points in the assumption it was an alias for a physical unit (it was defined as 1/72 of an inch), if points are not suitable I'd say get the DPI setting and calculate the monitor's size and use the % monitor as a unit.
I think I finally understood the problem. CSS px is supposed to depend on the DPI too. If I'm reading http://www.w3.org/TR/CSS21/syndata.html#length-units correctly, on a normal monitor situation (arm's length distance) a CSS px is 1/96 in. In my 132DPI case, 1px would be 1.375 physical pixels. So, for instance, 10px would be 13.75 physical pixels. 13px *is* almost the same as 10pt (it is 13.333...px), at least on the screen media, no matter the DPI, and should look the same size on the screen on every resolution and screen size. 12pt would be exactly 16 CSS pixels. While this is fine for a webpage, the default font size should be using points, since that's what all other programs use. Mozilla being different is confusing. At least give us the full power of CSS and allow us to use *any* absolute CSS lenght unit (plus the oddball px "relative" unit). Also, guidelines for what *page authors* should do don't apply to the default font size (since it's the user, not the page author, who is setting the size). I also have slight impression that Mozilla isn't treating px as depending on DPI as it should... If so, it's a bug.
(In reply to comment #26) > In the unusual circumstance described, you could/should run Mozilla from a > script that changes the DPI via user.js before starting Mozilla, or use > different profiles preset with the proper DPI for the display used. I'd argue that Mozilla's reliance on an internally stored DPI value is a broken design. At least in cases where the O/S provides such a value. The problem lies (as mentioned previously) where you want to use the same profile on multiple machines where each machine has a different screen size and DPI. > I don't think the argument made in the comment I was replying to is > justification for reducing user control. Points are for paper, not computer > displays, not since the growth of high resolution and high DPI anyway. At high > DPI, points are simply too coarse an adjustment for good control, unless > fractional sizes are offered in the prefs UI. However, users are used to using point sizes in many applications and have a very good feel for how big 9pt will appear on the screen. MSWindows uses point sizes in the dialog for configuring the user interface. My first assumption when I hit the fonts dialog in Mozilla is that those sizes are being specified in points, because that's what a lot of other programs do. The assumption issue could be fixed by suffixing "px" next to the size controls in the UI dialog rather then relying on the single statement at the top of the UI form. Showing a sample area of what size the displayed text will end up as would make for a good user-friendly long-term solution.
(In reply to comment #31) > Showing a sample area of what size the displayed text will end up as > would make for a good user-friendly long-term solution. That's ancient bug 33340, which you're welcome to fix. It really would eliminate any practical need to know or care what value is used to specify defaults. Trying to convert from a precise measuring system (what mozilla prefs use) to a coarse measuring system (pt) can make difficult the prevention of problems like that reported at http://qa.mandrakesoft.com/show_bug.cgi?id=8267 Being open source and highly dependant on contributed efforts, Mozilla doesn't need things to be made more difficult for these generous people that don't clearly benefit its users. Precision vs. familiarity is a debatable issue. A fix to this would produce an uncertain net user benefit or loss.
(in reply to comment #26) > The best thing would be to not only fix bug 33340, but as of a part of it > to include a slider for the adjusting, and the removal during selection > of any reference to what size is shown, letting the eyes decide without > the help of any numbers what size is the best. Sorry, but this does not deal with my daily problem: I use a notebook with an 120 dpi display that goes into a docking station with a 96 dpi monitor. The single Windows display dpi setting changes everything on my display to my liking, including the Firefox/Thundebird controls. Only the content displayed by Firefox/Thunderbird does not change, and I regard this as a bug (the work-around of changing the about 6 font-size numbers individually every time I enter or leave the office is inacceptable). This has nothing to do with the convenience of setting the font sizes, but rather consistency with the rest of Windows, with the Firefox/Thunderbird controls, and with sensible behaviour for users switching screens.
(Filter "spam" on 'prefs-nobody-20080612'.)
In the meantime, why don't someone go and put "px" in the dialog, for the sake of clarity? Having nothing affixed there surely confuses many first-time users (of the dialog)
The argument about points being coarse is moot. Even Windows 3.1 had a font selection dialog that alowed setting the font size in *either* of points and pixels recalculating the other size appropriately. Isn't that *most* control to the user which all point opposition calls for? Mozilla is some 20 years behind on this.
> In the meantime, why don't someone go and put "px" in the dialog, for the sake of > clarity? Currently the text says "Size (in pixels)"