Closed Bug 51748 Opened 24 years ago Closed 24 years ago

Fonts specified in pixels are unreadable on hi-res displays.

Categories

(SeaMonkey :: Themes, defect, P4)

Product:
SeaMonkey
Component:
Themes
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 51346
Milestone:
Future

People

(Reporter: jwbaker, Assigned: hewitt)

References

Details

(4 keywords, Whiteboard: nsbeta3-) 

Over the last week, several chrome font specifications have been changed from
points or other useful metrics to pixels.  Mozilla must not specify font sizes
in pixels.  For example, the personal toolbar font is now 11px high.  This is
completely unreadable on my high resolution display.

This is a regression because these fonts were formerly specified in sizes such
as points and mm, hwich scale properly with display resolution.  The change to
pixel sizes is a serious problem that needs to stop ASAP.

Here is a list of all pixel font sizes in skins:

modern/communicator/skin/button.css:12:      font                  : 11px arial;
modern/communicator/skin/button.css:233:    font-size			: 10px;
modern/global/skin/menu.css:204:    font-size             : 9px;
modern/navigator/skin/navigator.css:379:    font-size			  : 9px;
classic/global/skin/console.css:25:    font-size: 12px;
Nominating for beta3 consideration.  This is an easy, low-risk fix.  We don't
want to ship a beta that looks like a bad winamp skin.
Keywords: nsbeta3, regression
Summary: [REGRESSION] Chroms fonts being moved from points to pixels → [REGRESSION] Chrome fonts being moved from points to pixels
Summary: [REGRESSION] Chrome fonts being moved from points to pixels → Fonts specified in pixels are unreadable on hi-res displays.
I agree, this makes those areas of the product useless, even at 100 dpi.
rewriting summary, cc german for UE input, ben to get Classic skin fixed.
Please, please, don't go back to mm or pt which cause problems with low logical 

resolutions. What really is needed here is inheritance of the system-level UI font prefs or 

a Mozilla-level UI font pref.
Bug 16729 (use CSS system fonts for skins we ship) would fix this (assuming that
bug 33313, get CSS system fonts working on gtk, also got fixed).
Depends on: 16729
Depends on: 33313
I usually use a low-res 75dpi setting but I agree that pixels are the wrong unit.
I can switch between a low-res and a high-res setting and Mozilla should remain
readable. It doesn't. This is yet another loser.
This is only getting more ridiculous.  In Linux build 2000-09-13-12, fonts are
specified in pixel units in five places in the modern skin:

skins/modern/communicator/skin/button.css
skins/modern/global/skin/button.css
skins/modern/global/skin/global.css
skins/modern/global/skin/menu.css
skins/modern/global/skin/menulist.css

Now tooltips, the personal toolbar, the status bar, and buttons have fonts
pointlessly specified in pixel units.  CC hewitt due to bogus review on this bad
code.
Severity: major → critical
Keywords: access, fonts, newmod, ui
The default system font sizes needs to be used. I use a 74 dpi resolution, and
font sizes specified in physical units (e.g. points) are unreadable.
marking nsbeta3- and marking future.  We would like very much to make Modern 
support system fonts and allow for changing the font from a Pref inside the app; 
sadly there is no time to do either of these.
Assignee: nbhatla → hangas
Whiteboard: nsbeta3-
Target Milestone: --- → Future
You don't need to implement system fonts or prefs.  You need only go through the
CSS files substituting point sizes for pixel sizes.  This solves 99% of the
problems, and is a 1-second job for a competent editor.
As stated above, using points (or in, mm, pc or cm) is the *Wrong Way* and causes other 
issues (bug 17926 to be precise).
Changing the css is not possible.  If the fonts can change size then this will 
break the current implementation of the Modern skin.  We do not have time to 
make every area that has a font scale to the font size.  We do plan to do this 
after N6 is released.
Status: NEW → ASSIGNED
I'm getting rather bored of that argument.  Physical units are absolutely THE
ONE TRUE correct way to specify type sizes everywhere.  The only places that
physical units are inappropriate are on broken systems, such as the MacOS which
always ass-u-me-s 72 dpi.  

The correct solution here is to specify the chrome fonts in points.  The user
should set Mozilla's resolution preference to the right value.  On broken
systems, Mozilla can translate the specified font size to pixels, and request
the font from the system.  Permute this for varous platforms.

Good Example: MacOS user has a 100 dpi screen, MacOS assumes 72 dpi, and the
chrome type is 9 points, or 1/8th inch.  The type size should be 12.5 pixels
high on that user's display.  Mozilla, knowing the deficiencies of the OS,
rounds to 12 pixels and requests *either* a 12-pixel or 12-point font from the
OS.  The resulting type on the screen is in fact 8.640 points, which is
reasonably close to the desired size.

Bad Example:  MacOS user has 100 dpi screen, Unix user has 150 dpi screen,
chrome author specifies type at 11 pixels.  On the MacOS screen, the type is
close to 8 points, but on the Unix screen the type is only 5 points, which is of
course completely unreadable.  If the chrome author had instead specified 8
points, the type would be 11 pixels high on the Mac, and 17 pixels high on the
Unix box, and still readable in both places.

Pixels units are WRONG WRONG WRONG.
I have a ~15" monitor set to a resolution of 800x600. In Windows, the default 
DPI is 96. My monitor has a 74 DPI resolution (I've measured!). *If* the font 
size is specified in points, it will either look to small for people have set 
their logical resolution correctly, or too large for all the other (which 
haven't bothered to change it).
Your argument still sounds bogus to me.  If the resolution is set correctly the
font will not look "too large", it will be exactly the intended size!  Also you
fail to quantify "too large" and "too small".  If the fonts are in pixel units,
they will certainly be rendered at some random, unpredictable size.  Finally, if
someone has their resolution set incorrectly, there's hardly anything we can do
to kludge around that.  We aren't trying to hack around people whose proxies and
DNS are incorrectly setup, why should we cripple the product for people whose
screen resolution is misconfigured?

>I'm getting rather bored of that argument.

You still haven't proved it wrong.

Argument in the context of theory and the real world:
* Two users with identical screens may want to use differently sized fonts. Neither a 
particular fixed physical length nor a a particular fixed pixel length is good for both of 
them.

Arguments in the context of real world:
* Mozilla has no way of querying the hardware for the physical resolution. The 
correctness of the logical resolution depends on a guess or user input. The concept of 
"logical resolution" is more difficult to grasp than the concept of setting a font size pref. In 
reality, Mozilla will run in numerous environments with broken logical resolution values.
* Toolbar font sizes are generally at the lower end of the at all readable sizes. Supposing 
that Mozilla's font sizes are specified in points to be while Mozilla's default guess for 
logical resolution remains at 96 ppi, the font sizes that will become unreadable with 
reasonable ppi values (as Karl Ove descrived above and as described in bug 17926).
* If the point sizes are chosen to be readable at (eg.) 70 ppi and up, people who have set 
their logical resolution to 96 ppi will complain about the fonts being too large.

Making the UI font sizes user-settable and independent of the logical resolution and the 
Web content font size pref (either Mozilla-wide or using the system-wide settings) is the 
right way.

Physical units are WRONG, WRONG, WRONG
Fixed pixel sizes are wrong
Using user-settable sizes is RIGHT, RIGHT, RIGHT
> Physical units are WRONG, WRONG, WRONG
> Fixed pixel sizes are wrong
> Using user-settable sizes is RIGHT, RIGHT, RIGHT

And using system fonts (this includes system font sizes) is right, right, 
right ...
Adding myself and Paul Hangas to cc

Just an update - we're actually down to bug 55464 (a dependancy of bug 16729)
which is the only thing that is preventing modern from being "scalable" - right
now we have to use pixels because of the way a few of the wigets work. 

After that we can switch to the system font, so we won't be specifying the font
size in pixels or points, we'll just fall back to the system font.
Is this problem now fixed in the trunk builds, where both Modern and Classic now
adopt system fonts?
> Is this problem now fixed in the trunk builds,
> where both Modern and Classic now
> adopt system fonts?

Does Modern also use system fonts? Great! But the answer would still be no, 
since bug #51346 isn't fixed yet.
Adding dependancy.
Depends on: 51346
Sending to Hewitt.
Assignee: hangas → hewitt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: P3 → P4
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
dup


*** This bug has been marked as a duplicate of 51346 ***
Verified dup
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.