17926 - Chrome on Mac is unusable at 72 dpi

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Simon Fraser [no longer active]]

To get Mac-traditional page layout, you can set the pref
pref("browser.screen_resolution",72). (this only works now if you change one of
the default prefs files).

The problem is that this affects chrome as well as content, and with it on, all
the fonts in the UI are way too small, and mostly unreadable.

We need a solution whereby we can specify absolute font sizes for the UI, so that
we can guarantee that the user will get a font at a size that renders nicely.

Comment 1

[Pierre Saslawsky]

How funny! I saw the problem myself yesterday even though it has been around

for several months. I was getting tired of the big fonts in the HTML area and,

like you, I noticed that the chrome was unusable in 72 dpi.



Here is what our master Peter Linss said in his very first message on the matter

(the full text is on news://news.mozilla.org/37126623.E5B0BD50%40netscape.com):



   This needn't affect our chrome on the Mac. For the chrome

   we can either specify the units in pixels instead of points, or

   keep the scale to 72 dpi for the chrome part (gfx/nglayout can

   handle that).



I don't know what the best solution is: revisit the chrome to change all the

measurements to pixels or use a dpi of 72 in the webshells used by the chrome (if

that's the way to do it - I haven't looked into it). You may want to check with

the XPToolkit team.



Changing the title to "Chrome on Mac is unusable at 72 dpi" from "With

pref("browser.screen_resolution",72), fonts in UI are too small"

Comment 2

[german]

the plan is to use an absolute size, probably 3 or 3.5 mm, such that that problem
should go away. I'll still leave the bug assigned to me, so we can keep track of
the progress.

Comment 3

[german]

actually it is not hard to change the chrome font size specifications since they
are defined only once in global.css window. All other elements (contained by
window) are iether inheriting this value or specifying theirs relative to it
(e.g. by using "smaller" for status bar). Thus experimentation will be simple.
Finetuning font sizes is something we intended to do past dogfood.

Comment 4

[Pierre Saslawsky]

It would be nice also to use the CSS2 font names so that it displays in Geneva on
the Mac instead of Helvetica. Note that CSS2 fonts are not fully supported yet
(that's bug 3371 assigned to me).

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

mm units work just like pt.  They go through the logical resolution.  I would
think a font-size pref for the chrome would be the best solution here, though...

Comment 6

[german]

Yes that is what I was thinking too, even if we allow changing only within
reasonable boundaries, where reasonable could be defined as still being able to
display the widest dialog within 800*600 (target screen size). To keep it simple
 for beginners we could offer predefined font sizes. If we can't do that the
second best solution would be to have alternative skins that just differ in font
size (.css files).

Comment 7

[leger]

Updating QA contact and component

Comment 8

[german]

last time I talked to hyatt and a bunch of other XCP Toolkit people, they were
not thinking that this was a good idea. Their thinking is that we cannot even
make the assumption that with skinned interfaces there is such a thing as a
global font. Their thinking is that we do tweaks and ship platform specific font
styles for the default skin to make it look good for the 90% cases on each
platform.  Rather than paraphrasing them I will cc' them so they can explain
their viewpoint better.

Comment 9

[Pierre Saslawsky]

Whatever you decide, please don't try to re-create with the alternative skins
what Apple tried to do with the Appearance Manager. The chrome should use the
CSS2 fonts, and thus the platform specific settings in nsLookAndFeel for system
fonts and sizes.

Comment 10

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 11

[german]

Coming to think some more about this problem, global.css should probably differ 
in terms of 'base font' for those more problematic platforms like Linux and mac. 
Thoughts?

Comment 12

[Erik van der Poel]

As Pierre suggested twice in this bug report, and as I suggested in the
newsgroups, the skins ought to use CSS's "system fonts", which are by definition
system-specific, so Mac and Linux can get appropriate fonts that way (and
Windows too of course).

Comment 13

[Henri Sivonen (:hsivonen)]

The physical screen resolution of modern Mac configurations isn't really 72 ppi. The 
logical resolution should not be set to 72 ppi, if that isn't really the physical resolution. 
See: http://www.pp.clinet.fi/~henris/en/units.html

The only way to duplicate the system-wide UI font sizes without sticking to outdated ppi 
assumptions, is to get the *pixel* sizes of UI fonts from Mac OS.

Comment 14

[shuang (gone)]

I don't think this one can be done/decied around M16. Push to M18 for final 
call when globle skin/fonts issue is more clear.

Comment 15

[german]

This applies to modern skin only I assume. I think this was fixed with the recent 
checkin to fix 'modern' fonts in general while it was also fixed for Linux. See 
bug 5236. marking worksforme

Comment 16

[Simon Fraser [no longer active]]

Reopening. I'll show you what it looks like with a screenshot...

Comment 17

[Simon Fraser [no longer active]]

Attachment: Screenshot of the UI with resolution set to 72dpi, default font settings

Comment 18

[german]

I noticed you are using a 6/14 build in the screenshot - may this be the cause? 
(The bug I mentioned was fixed about a month after that)

Comment 19

[Pierre Saslawsky]

German: when you build from a fresh tree, Mozilla displays a build id of 2000-06-
14, I don't know why (was it the last time we branched?). I trust Simon to have 
taken the screen snapshot with a really recent build.

Comment 20

[Simon Fraser [no longer active]]

That build was from today. The build ID does not update in the Mac debug builds 
if you don't have a perl tool correctly installed.

Comment 21

[Henri Sivonen (:hsivonen)]

There are two ways to fix this with different correctness levels:
1) Define all font sizes in *px* matching the platform default (better than the
current way)
2) Inherit the actual *px* size from the OS (correct)

In any case, using pt, cm, mm, in or pc is asking for trouble.

CCing nbhatla, since there are pt font sizes in the Mac Classic theme.

Comment 22

[Henri Sivonen (:hsivonen)]

*** Bug 53089 has been marked as a duplicate of this bug. ***

Comment 23

[hangas]

marking nsbeta3- while assigned to german

Comment 24

[german]

Can this problem still be seen with the current setup of modern? I assume this
went away (it looks fine on my Mac). If not this bug is related to bugs 5236 and
47059.

Comment 25

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

When testing, did you set the pref described in the first comment above?

Comment 26

[Adam]

I'm still seeing this bug in the Modern2 and Blue skins. Setting the fonts to
72dpi changes text for the location field, preferences and other interface
items. Looks exactly like the screenshot. This really needs to get fixed for RTM
if changing the dpi is going to be allowed.

Comment 27

[Adam]

*** Bug 53202 has been marked as a duplicate of this bug. ***

Comment 28

[german]

I propose reassigning this bug to ben, the mozilla UI owner, so he can add this
to his 'ongoing discussions bin'
. One of the things being discussed for a later release is investigating how
well system fonts would solve this problem in the modern skin, as I believe this
bug mostly affects modern. Now that system fonts can be reliably spec'd through
CSS we can give that a try.

Comment 29

[Matthew T (active 1999-2002)]

And not only did he propose reassigning it, he actually did reassign it!

Yes. Bug 16729 would fix this for the Modern skin, but it would not fix the 
problem for other skins that were made using points on non-Mac systems. For that 
the Mac would need to use 72 dpi for chrome, regardless of the dpi setting used 
for content.

Comment 30

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 31

[timeless]

does anyone actually have a proposal about what to do?

Comment 32

[Asa Dotzler [:asa]]

helping Ben with his buglist maintenance.  This bug will not be fixed for M18.

Comment 33

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 34

[Paul Chen]

Marking nsbeta1-, p3, future, doesn't look like this will be solved in the beta1
timeframe.

Comment 35

[mbirth]

I experimented a bit around (instead of using an old chrome, where the fonts had
"readable" size, like before) and found out that if you delete all occurences of
"font: menu;" and "font: message-box;" the font size gets back to 8 or 10pt. And
this is exactly the size I wanted to have. I don't know why it works - but it works.
Seems like Mozilla has problems interpreting those default CSS2-font-definitions
like message-box and menu.

Comment 36

[Ben Goodger (use ben at mozilla dot org for email)]

Is this still a problem?

Comment 37

[Pierre Saslawsky]

It works for me.  Marked fixed.

QA: please test with different skins at different dpis (72/96/150 for instance).  
I'll attach a small testcase using absolute units that allows you to verify that 
you are in the correct dpi.

Comment 38

[Pierre Saslawsky]

Attachment: testcase in absolute units

Comment 39

[Greg K.]

Pierre, your latest testcase comes close, but not quite.

Returning to the Fonts Preferences dialog, I determined that the length of the
line in the Display Resolution dialog was 3.6cm, resulting in a DPI of 104. This
is the actual resolution of my Viewsonic PF815 display at 1600 by 1200 pixels.

However, upon viewing the testcase, the credit card was 9.2cm by 5.9cm, a little
short of real CC dimensions. Likewise, the text was 2.35cm tall, a little short
of an inch.

Comment 40

[Pierre Saslawsky]

Per the spec (http://www.maxking.com/cardstandards1.htm), a credit card is 85.6mm 
by 53.98mm.  The dimensions in the testcase are 8.5cm by 5.3cm (to measure the 
card, I used the ruler at the back of a Lonely Planet guide that doesn't show the 
millimeters - still quite close).

In the font prefs panel, I evaluated the length of the line to be 1.5 inch (or 
3.8mm) which gives a DPI of 98.  The difference between your measurement (36mm) 
and mine can be explained by the parallax.  When you measure the line on a CRT 
screen, you have close an eye, put the other one right in front of the left-hand 
side of the line and make sure it is aligned with the ruler.  Then move the eye 
in front of the right-hand side of the line and read the length.  If you keep the 
eye aligned with the center of the line, you can read 36mm.

Comment 41

[Daniel Kabs, reporting bugs since 2002]

Hi!

I hope I understand this bug correctly. Let me summarize: Changing
Preferences->Appearance->Fonts->Display Resolution *should not* change the UI
font size.

If this is the case, then I wonder why changing this setting *does affect* the
UI font size *if* I have a userChrome.css in my profile folder? Is this another bug?

Btw, I'm running Linux here.

Comment 42

[Daniel Kabs, reporting bugs since 2002]

Attachment: Shows Mozilla rendering at different mozpref-DPI settings

Screenshot, taken with different settings of 
Preferences->Appearance->Fonts->Display Resolution 
and with/without userChrome.css used.

Having userChrome.css, Display Resolution affects not only the content, but
also the chrome. Bug or feature?

Comment 43

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Feature.

Comment 44

[Daniel Kabs, reporting bugs since 2002]

(In reply to comment #43)
> Feature.

This feature is difficult to use: Only the elements listed in userChrome.css
respect the Preferences->Display Resolution setting. For my UserChrome.css (see
attachment #193136 [details]) this is only the menu bar and the context menu. Thus e.g.
the preferences dialog or the "Go" button are still ignorant of my Display
Resolution setting.

What do I have to write in userChrome.css to make the /complete/ UI fonts
respect my Display Resolution configured in Preferences? Is there a "general"
element that I can configure so all other elements inherit this behaviour?

Comment 45

[Daniel Kabs, reporting bugs since 2002]

(In reply to comment #44)
> What do I have to write in userChrome.css to make the /complete/ UI fonts
> respect my Display Resolution configured in Preferences? 

Found the answer: Inserting into userChrome.css

* {
  font-size: 3.5mm !important;
}

does the trick. I'm chuffed :-)

Cheers
Daniel Kabs

Comment 46

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

FWIW, the logical resolution pref affects interpretation of sizes specified in
physical units (e.g., mm, cm, in, pt), but not in other units (e.g., px, em, %).
 By default, the system font code should be providing system fonts as though
they are specified in px units, so they work at any logical resolution.