Simon Fraser [no longer active] Reporter
	Description • 25 years ago

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.

	Pierre Saslawsky
	Comment 1 • 25 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"

	german
	Comment 2 • 25 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.

	german
	Comment 3 • 25 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.

	Pierre Saslawsky
	Comment 4 • 25 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).

	David Baron :dbaron:
	Comment 5 • 25 years ago

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...

	german
	Comment 6 • 25 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).

	leger
	Comment 7 • 25 years ago

Updating QA contact and component

	german
	Comment 8 • 25 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.

	Pierre Saslawsky
	Comment 9 • 25 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.

	leger
	Comment 10 • 25 years ago

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

	german
	Comment 11 • 25 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?

	Erik van der Poel
	Comment 12 • 25 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).

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 13 • 25 years ago

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.

	shuang (gone)
	Comment 14 • 25 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.

	german
	Comment 15 • 25 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

	Simon Fraser [no longer active] Reporter
	Comment 16 • 25 years ago

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

	german
	Comment 18 • 25 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)

	Pierre Saslawsky
	Comment 19 • 25 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.

	Simon Fraser [no longer active] Reporter
	Comment 20 • 25 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.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 21 • 25 years ago

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.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 22 • 24 years ago

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

	hangas
	Comment 23 • 24 years ago

marking nsbeta3- while assigned to german

	german
	Comment 24 • 24 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.

	David Baron :dbaron:
	Comment 25 • 24 years ago

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

	Adam
	Comment 26 • 24 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.

	Adam
	Comment 27 • 24 years ago

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

	german
	Comment 28 • 24 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.

	Matthew T (active 1999-2002)
	Comment 29 • 24 years ago

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.

	Oliver Klee
	Comment 30 • 24 years ago

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

	timeless
	Comment 31 • 24 years ago

does anyone actually have a proposal about what to do?

	Asa Dotzler [:asa]
	Comment 32 • 24 years ago

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

	Zach Lipton [:zach]
	Comment 33 • 24 years ago

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...

	Paul Chen
	Comment 34 • 24 years ago

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

	mbirth
	Comment 35 • 24 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.

	Ben Goodger (use ben at mozilla dot org for email) Assignee
	Comment 36 • 23 years ago

Is this still a problem?

	Pierre Saslawsky
	Comment 37 • 23 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.

	Greg K.
	Comment 39 • 23 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.

	Pierre Saslawsky
	Comment 40 • 23 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.

	Daniel Kabs, reporting bugs since 2002
	Comment 41 • 19 years ago

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.

	Daniel Kabs, reporting bugs since 2002
	Comment 42 • 19 years ago

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?

	David Baron :dbaron:
	Comment 43 • 19 years ago

Feature.

	Daniel Kabs, reporting bugs since 2002
	Comment 44 • 19 years ago

(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?

	Daniel Kabs, reporting bugs since 2002
	Comment 45 • 19 years ago

(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

	David Baron :dbaron:
	Comment 46 • 19 years ago

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.