Following #5000, we need a small dialog on the Mac and maybe Unix to adjust the screen resolution (72 dpi, 96 dpi, etc...). The name of the preference is "browser.screen_resolution". It's an 'Int' and its default value should be 96. Per <mcmullen>, assigned to <matt>.

Set milestone to M9. Pierre, I'm not sure what you mean by dialog. A prefs panel? Can we run this by German or Scott in UE and get some feedback on this?

Yes, a prefs panel. They have something like that on Windows as an OS Control Panel and we are supposed to do something similar in the Mac and maybe Unix preferences. Any input is welcome (I think that ScottY is on sabattical these days). CCing Ramiro to implement the "browser.screen_resolution" pref on Unix if necessary.

I will add the "screen_resolution" pref to Unix (GTK).

OK, I have checked in the code to read "browser.screen_resolution" for GTK. If that pref is set to zero (0), it will use the X server's dpi value. If the pref is not set, it uses a default of 96.

Updating QA Contact from paulmac to cpratt

erik, do we still need this? I nevcer was told what the ui should look like but i figure it will be a select list if we still want this.

Pierre, I believe PeterL had specific ideas for this. Do you know what they were? I have not been able to locate the Windows control panel related to this. I thought Peter mentioned something about a "ruler" that the user would use to set an appropriate resolution...

To find that control panel (in Windows 98 at least): - Right-click on the Desktop - Select Properties - Click the Settings tab - Click the Advanced button - Change the Font Size setting to Other... I think that's probably what you were looking for.

Peter Linss provided a sample UI in the following news message: news://news.mozilla.org/37126623.E5B0BD50%40netscape.com

Using a ruler we will need to create a custom widget for this since the ruler has to be dragged. German, Is there any other way do create a UI for this and is this a feature we want in the prefs?

The ruler was just a suggestion based on the Windows control panel. You are certainly free to design the UI you want.

OK, after talking to pav, matt, mcafee and others, we've decided that doing a ui to control screen resolution is probably the wrong way to solve the problem. I'm passing this off to pav for him to add exciting and more detailed commentary.

What was the reason? I think I have a body willing to do the UI if it is a resource problem.

ben seemed to be volunteering to do this... :)

the pref needs to be done as a platform specific overlay so that it does not appear on windows or unix.

If that's the verdict on this, then Unix needs to be changed to use the X server info by default. Currently, the default is 96 ppi, and the X server setting is honored by setting browser.screen_resolution to 0 in prefs. I guess, then, that the easiest thing to do would be to set the pref to 0 in the default prefs file. Should a separate bug be filed on this?

accepting, will proceed with caution & discussion. post comments & suggestions here.

For the benefit of those that did not attend the meeting between Don, Pav, Matt, McAfee and others, would someone please briefly explain why this UI was deemed unnecessary on Unix? Is it simply because the user can get the X server to emit the correct dpi value through some special sys admin-like procedure?

Erik, Pavlov can best answer that question. I'll defer to him.

This UI is just as necessary on Unix as it is on the Mac. Most Unix systems don't calculate the DPI correctly by default.

Move to M15. Not required for beta 1.

partial fix checked in (UI enabled on all platforms, pref present but supposedly buggy on Mac) I might get around to designing a better UI eventually. Here's what I have: /-[ Font Scaling ]------------------------------------------------\ | | | Set resolution for displaying fonts (<-- better text than this) | | | | Resolution: [ 96 ] dpi (e.g. 96 dpi) | | | \-----------------------------------------------------------------/

Problem in that dialog on Linux build 2000.01.17.08 1. Open fonts prefs 2. Enter new DPI value, click OK Actual result: prefs dialog is not closed Console output: *** VALUE= *** VALUE=0 *** VALUE= *** VALUE= *** VALUE= JavaScript Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPref.SetCharPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://pref/content/pref.js :: PREF_ParsePref :: line 151" data: no] Switching to another prefs panel and back shows that DPI value is not saved. Expected result; prefs dialog closes, new DPI value set

the current implementation suits me fine, and no one has complained or sent in a better one ;) I dont see the js exceptions any more, I assume this was prefwindow landing teething troubles.

Reopening: the current interface really sucks. We need something based on the UI suggested by peterl (see my comments from 1999-11-02 19:38). The ideal would be a dialog like the one peterl proposed but with the following modifications: - Forget about the draggable ruler: the screen resolution can be entered in an editable fields like we have now and validated with an [Apply] button. - We need not one but two rulers: one in inches, one in centimeters. - The dialog should contain some help text saying something like "Put a ruler on your screen, if it doesn't match the ruler from the dialog, change the dpi value and click Apply. Repeat until you find a value for which the ruler from the dialog matches the real-world ruler".

Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.

Keyboard mnemonics (aka, menu access keys, keyboard accelerators) for Linux have been disabled for the time being. Refer to following for details: bug 22515 bug 27644 bug 24413

gah! pls ignore my last comment --wrong bug!

A few weeks ago we had a rather big discussion about screenresolutions in th n.p.m.layout newsgroup. We landed on a prefs panel that had theese options: * Always use system setting * Use systemsetting if above [textbox] dpi * Set to [textbox] dpi And below a ruler with inches and centimeters. The ruler isn't dragable but only shows the current setting, so there is no need for a new widget. The default would be "Use systemsetting if above [96] dpi" I don't remember if we discussed where this panel should be placed, but my suggestion is in the Advanced group so that people don't use this to configure fontsizes.

not a priority, pushing out as far as possible.

Move to M21 target milestone.

This bug is fixed, the textfield is good enough for 1.0. We should open another bug for the ruler UI, I'll let caring parties do that. Marking WFM since a fix has been in place for a while. QA: This is the text field in Prefs|fonts panel.

Changed the Summary to "Need a dialog with a nice ruler to set the screen resolution" from "Need a dialog to set the screen resolution", and reopened.

Also we need to change the wording. The current position and wording gives the impression that only fonts are affected by this

A dynamic ruler is quite some work. As an intermediate solution, I propose replacing the dpi value with "width of the screen as displayed on my monitor (in mm)". Calculating the dpi from that is simple, and this measurement is much easier to understand than the concept of dpi resolution. Furthermore, the Unix platforms have the option of taking the dpi from the X server. This is signalled by a dpi value of 0, but this fact is quite obscure. Better to have a way to switch that on/off easily (radio button, perhaps?).

we could provide both the mm UI and the DPI, and have a separate radio for unix-only.

Gerv has a preliminary ruler dialog done in his fix for bug 28899. Once that's in, we'll refine it based on the comments in this bug.

There are some _horrible_ UI suggestions in this bug :-) Could I please have feedback on the current UI, which is: There's a fixed 300px long bar in the dialog. Measure it, and input the length (in either inches or centimetres; there's a dropdown to select which.) Press OK. I then do (300 / length-in-inches) to get a DPI value. If we want to get the value from the X server, or whatever, and there's a way to do this from JS, then we can add a "Get settings from system" or similar button alongside "OK" and "Cancel" to this dialog. But really, what's the point? It'll just produce the same value as someone using a ruler. Gerv

That's one possibility. The other possibility is the really cool ruler found in Windows 95's resolution dialog, which you could drag to be the same size as a real ruler put against the screen. You would then do actualLengthOfOnScreenRuler / markedLengthOfRuler = resolution e.g. if the ruler is marked as being 10cm and is dragged until it is 378px long, then the resolution is 96dpi [1]. Ideally you would mark the ruler in both centimeters and inches. This should be relatively easy to do using a bit of XUL and CSS. [1] 10cm / 2.54 = 3.937in, 378px/3.937in = 96dpi

This UI works for me. But who has a ruler nearby? I don't have one at work, that's for sure. How about a common length, like a 12cm CD? Or half that amount, measure the radius. Put a pixel ruler on the screen and user would read off pixels.

The CD idea might fly. But I have no idea how to make the ruler draggable. Can we agree that the current UI is good enough to be checked in as a first effort, at any rate? If we want to implement draggability later, we can do that. There are screenshots in the other bug, remember - although they are a touch out of date now. Gerv

Heh, a CD would be cool. We could quite easily have a ruler which looks like: +----+----+----+----+----+----+----+----+----+----+----+----+----+----+---+ | 1cm 2cm 3cm 4cm 5cm 6cm 7cm 8cm 9cm 10cm 11cm 12cm 13cm 14cm | | | | | Diameter of a CD | | | | 1in 2in 3in 4in 5in | +------------+-----------+------------+------------+-----------+----------+ The only thing we have to make sure is that: The cm markings are equally spaced The in markings are exactly 2.54 times further apart than the cm markings The CD marking is exactly aligned with the 12cm marking. The drag and drop behaviour would work like this: when you click on the ruler, that point *relative to the markings* is stored. When you drag, the ruler is resized such that the point under the cursor has the same position relative to the markings as when you started the drag. I would recommend making the ruler size so that it always fits in the dialog (so if have a huge 1dpi monitor, the ruler would grow to still fit the dialog). So as you drag the ruler on the screen, it gets more and more or less and less markings. Of course I'm just saying what I'd find most useful myself. mpt will tell us what is best for real users! :-)

Amazing, on my monitor/font combo hixie's ASCII ruler is only about 1 mm off. Gervase: If you're thinking about a "Get dpi values from" action-button that fetches the value and stores it, that's wrong -- think about people using the same homedir/profile on different machines. A radio or checkbox that disabled the manual (ruler or whatever) setting, and enabled the functionality to *always* get dpis from X server on startup would be preferable. We already have this functionality: just set dpi to 0. Only the UI is lacking. My concrete suggestion is to have no override (i.e. get from system) by default. The ruler thingy is greyed out, but already sized according to our current idea of dpi. If that is way off, you can check a "override system dpi settings" box, which ungreys the manual override section.

The current dialog is really simple - simple enough for anyone to understand. The only possible drawback is that it requires a ruler. Is this really a massive drawback? If it is, we can change the text to read something less clunky than "Measure the bar above and enter the length below, or resize the window until the bar is the same length as an object of known width, e.g. a 12cm CD, and enter that value" If you want smart rulers and all sorts of other funky stuff, you can do them yourselves :-) The current dialog supports the ruler method and, with a text change, the resize method. That is sufficient for me, and there's more important UI issues to work on :-) Gerv

Sure, but shouldn't you adjust the priority, then? Or set "helpwanted" or whatever ...

Yeah, you are right. Gerv

What about using a 3.5" diskette instead of CD? It is more smaller, it is everywhere and has a fixed size too... The only concern maybe it can be actually erased (I don't know if monitors has high magnetic areas). Just a tought.

> ... it is everywhere ... Users of iMacs probably won't agree. Anyway, it's not an either or decision. I like hixie's "ruler with inch, cm, and a CD mark" idea. We can put a dash on that for the 3.5 as well. Only problem: the hull is 3.5 by 3.8 inches. You'd have to specify "short side" or something.

A credit card would be a nice ruler.

has anything happened on this since then? (bug cleaning)

I stumbled on http://personal.riverusers.com/~swilhelm/gtkperl-tutorial/ruler.html looking for a screen ruler. Maybe it would be a starting point for someone who would like to fix this.

related - bug 17861, bug 11709, bug 24227

A CSS inch is now defined in terms of CSS pixels. This bug can be closed.

(In reply to comment #53) > A CSS inch is now defined in terms of CSS pixels. This bug can be closed. I disagree. That anything external is tied to pixels is a bug. I expect that defining absolute units in terms of pixels without regard to screen resolution will eventually be reversed.

browser.screen_resolution does not seem to exist on trunk. =>INVALID?

browser.screen_resolution was replaced by layout.css.dpi