Closed
Bug 17926
Opened 25 years ago
Closed 23 years ago
Chrome on Mac is unusable at 72 dpi
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: sfraser_bugs, Assigned: bugs)
References
Details
(Keywords: arch, helpwanted)
Attachments
(3 files)
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•25 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•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"
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.
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•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).
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...
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).
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•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.
Comment 10•25 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
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?
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).
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•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.
Target Milestone: M16 → M18
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
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 16•25 years ago
|
||
Reopening. I'll show you what it looks like with a screenshot...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 17•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Keywords: correctness,
nsbeta3
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)
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.
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.
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 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.
Status: REOPENED → ASSIGNED
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.
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.
Assignee: german → ben
Status: ASSIGNED → NEW
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.
Comment 30•24 years ago
|
||
Milestone 0.8 has been released. We should either resolve this bug or update its milestone.
Comment 31•24 years ago
|
||
does anyone actually have a proposal about what to do?
Whiteboard: nsbeta3-
Comment 32•24 years ago
|
||
helping Ben with his buglist maintenance. This bug will not be fixed for M18.
Priority: P3 → --
Target Milestone: M18 → ---
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...
QA Contact: claudius → zach
Comment 34•24 years ago
|
||
Marking nsbeta1-, p3, future, doesn't look like this will be solved in the beta1 timeframe.
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.
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.
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → FIXED
Comment 38•23 years ago
|
||
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.
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
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.
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?
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?
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
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•