Open Bug 186718 Opened 22 years ago Updated 4 years ago

mozilla uses pixels instead of points for "default font size" setting

Categories

(SeaMonkey :: Preferences, defect)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: jruderman, Unassigned)

References

Details

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?
Summary: mozilla uses strange units for "default font size" setting → mozilla uses pixels instead of points for "default font size" setting
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.
OS: Windows XP → All
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.
Product: Browser → Seamonkey
(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.
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
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)"
You need to log in before you can comment on or make changes to this bug.