Chrome on Mac is unusable at 72 dpi

RESOLVED FIXED in Future

Status

defect
P3
normal
RESOLVED FIXED
20 years ago
14 years ago

People

(Reporter: sfraser_bugs, Assigned: bugs)

Tracking

({arch, helpwanted})

Trunk
Future
PowerPC
Mac System 8.5
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

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.

Updated

20 years ago
Summary: With pref("browser.screen_resolution",72), fonts in UI are too small → Chrome on Mac is unusable at 72 dpi

Comment 1

20 years ago
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"

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 2

20 years ago
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.

Updated

20 years ago
Target Milestone: M14

Comment 3

20 years ago
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

20 years ago
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).
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

20 years ago
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).

Updated

20 years ago
Component: Browser-General → UE/UI
QA Contact: leger → claudius

Comment 7

20 years ago
Updating QA contact and component

Updated

20 years ago
Target Milestone: M14 → M16

Comment 8

20 years ago
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

20 years ago
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

20 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback

Updated

20 years ago
Blocks: 28883

Comment 11

20 years ago
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

20 years ago
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).
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

19 years ago
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.
Target Milestone: M16 → M18

Comment 15

19 years ago
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
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Reporter

Comment 16

19 years ago
Reopening. I'll show you what it looks like with a screenshot...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter

Updated

19 years ago
Keywords: correctness, nsbeta3

Comment 18

19 years ago
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

19 years ago
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.
Reporter

Comment 20

19 years ago
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.
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.
*** Bug 53089 has been marked as a duplicate of this bug. ***

Comment 23

19 years ago
marking nsbeta3- while assigned to german
Whiteboard: nsbeta3-

Comment 24

19 years ago
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.
Status: REOPENED → ASSIGNED
When testing, did you set the pref described in the first comment above?

Comment 26

19 years ago
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

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

Comment 28

19 years ago
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.
Assignee: german → ben
Status: ASSIGNED → NEW
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

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

Comment 31

19 years ago
does anyone actually have a proposal about what to do?
Keywords: nsbeta3arch, helpwanted
Whiteboard: nsbeta3-
helping Ben with his buglist maintenance.  This bug will not be fixed for M18.
Priority: P3 → --
Target Milestone: M18 → ---
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...
QA Contact: claudius → zach

Comment 34

19 years ago
Marking nsbeta1-, p3, future, doesn't look like this will be solved in the beta1
timeframe.
Keywords: nsbeta1-
Priority: -- → P3
Target Milestone: --- → Future

Comment 35

19 years ago
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.
Is this still a problem?

Comment 37

18 years ago
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.
Status: NEW → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 39

18 years ago
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

18 years ago
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.

Updated

17 years ago
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
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.
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?
(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?
(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
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.
You need to log in before you can comment on or make changes to this bug.