83061 - Allow direct entry of DPI value in font prefs

Status: RESOLVED WORKSFORME

(SeaMonkey :: Preferences, enhancement)

Description

[Ben Bucksch (:BenB)]

[Font system]
[Font pref UI]

I want to be able to set an arbitary dpi value directly, in the UI.

Until recently, there was a textfield where I could do that. Now, I have only a
dialog where I have to measure the length of a line on the screen. Regression.

This is especially bad together with bug 83060.

On X, you set the spi in the X server already, so you already know an exact
value. In other words, the current solution seems pretty useless to me on X.
Easy fix. -> mozilla0.9.2 nomination.

Comment 1

[Gervase Markham [:gerv]]

Oh, stuff off :-)

There is no point whatsoever in complicating the UI for the 0.01% of people who 
both know what a dpi value is and happen to know the exact value for their 
monitor. Picking it up automatically from the X server would be a good thing, 
and if you want this bug to be about that, fine.

You'll be wanting three text fields for RGB hex values in the colour picker, 
next...

Gerv

Comment 2

[Gervase Markham [:gerv]]

In fact, the X server bug is bug 81904.

Gerv

Comment 3

[tenthumbs]

Well, piffle!

Mozilla should just ask the X server what it's resolution is and use it.
I can, after all, set the DISPLAY environment variable and use any X
server I can reach.

Of course, this does mean mozilla needs a UI check box to override the
server plus a text box for the new value. :-)

Comment 4

[Gervase Markham [:gerv]]

Please see bug 81904 for getting the value from the X server. 

We can do one of two things with this bug - either dupe it against that one, or 
mark it WONTFIX. There is no _way_ I am adding textbox UI for people to type in 
DPI values themselves.

Gerv

Comment 5

[tenthumbs]

That kind of attitude will just bring a world of pain in the Unix
environment. There are many systems, many X servers, and a whole lot of
incompatibilities. Expecting all of them to operate the way you think
they should is silly. There's absolutely no reason to assume that all X
servers on all platforms, or even all X servers on one particular
machine, operate the way you would prefer.

Don't get me wrong. Making life simpler for users is a Good Thing.
Unfortunately, it is sometimes very difficult to do in the Unix world.
Closing off user access to troubleshooting procedures seems like a bad
idea to me.

Comment 6

[Gervase Markham [:gerv]]

<sigh> Have you actually looked at the current UI?

You can either set it to 72dpi, 96dpi, or measure your screen and set it to any 
value you like. When we add "Ask the X server", you'll be able to do that too.

In what circumstances would you therefore need to enter a value directly? 
- Your X server's DPI settings are wrong AND
- you have no way to correct them AND
- 72 and 96 are also both inaccurate AND
- you don't have access to a ruler.

Gerv

Comment 7

[tenthumbs]

Yes, I have looked at the UI. In fact, I just grabbed the latest nightly
to check. The first thing I notice is that what appears to be a text
entry box actually isn't. You can't type into it. If it looks like a
text entry box, it should be one; otherwise, use something else.

As for the rest, consider this example. It's almost a real example
because I have, in fact, done exactly what I describe. I walk into a
conference room for a meeting. Dominating the room is a large display
monitor mounted high up on the wall so everyone can see it. There's an X
server somewhere that can display on it. I can sit down, connect my
laptop to the LAN, and make pretty pictures in the big screen. What I
don't know is where the computer actually is, what OS it's running, what
X server it's running, or how that X server is configured. What I do
know is that I am using well-defined officially sanctioned features of
the X protocol.

Now what to do if images look bad? Perhaps, it's a bad X server or an
old X server. Perhaps, it's misconfigured. Who knows. All I know is that
I would expect mozilla to provide me with a way of solving the problem.
Your scheme provides none. Since it's a large screen, it's probably not
72dpi or 96dpi. To measure it, I would need a ladder, a tape measure,
and an assistant. Not likely.

You have implicitly assumed that the monitor is within arm's reach. You
have assumed that a user has the physical capability to measure the
monitor if necessary. That's an accessibility issue and must not be
ignored. You have assumed that the user has no other knowledge about the
correct setting so she is stuck with measurements. You have assumed that
the user can make a reasonable measurement. Given the unknown curvature
of the screen I doubt that's likely.

Finally, neither 72 nor 96 are correct values. They should be 75 and 100
for X servers with the standard fonts. Mozilla just looks dumb not
knowing that.

Now you may think that a 4% error is negligible but you would be wrong.
I know. Given mozilla's preference for bitmap fonts, given the fact that
mozilla thinks in pixels rather than points as the X server does (bug
40373), and given some round-off (off-by-one) errors in the bitmap fonts
themselves, a 4% error can produce a bad display.

You are just making far too many assumptions about how things work.

Comment 8

[Gervase Markham [:gerv]]

Where is this text box you can't type into? The dpi pref is a drop-down list 
box, and it looks exactly like the nine others on that prefs panel.

I repeat: please see bug 81904 for getting the value from the X server. We are 
going to implement that - I have never said we are not.

If the X server on your massive wall-mounted monitor is broken, it's not 
Mozilla's fault.

Regarding 96 vs. 100, that's a separate bug, which I don't know anything about. 
I just used the values that were there before. If you want this changed, file 
another bug, and don't CC me. :-)

This type of UI (measure the screen) is used by every other app (e.g. The Gimp) 
which needs this info. and has no other way of getting it. There is no 
justification for making the UI more complicated than it is now. 

No, no, and thrice no.

Gerv

Comment 9

[Ben Bucksch (:BenB)]

> I repeat: please see bug 81904 for getting the value from the X server. We
> are going to implement that - I have never said we are not.

When? Unless you implement it in the next release, this argument is irrelevant.
Adding a textfield is way easier.

> There is no point whatsoever in complicating the UI for the 0.01% of people
> who both know what a dpi value is and happen to know the exact value for
> their monitor.

Sorry? If people don't know, what a dpi value is, why do we have the UI to set
it at all? If nobody knows the exact values, why can I select 2 of them (72 and
96)???

I'm just saying that I don't want to be constrained to 2 predefined values.
Doing something like that is only right to do, if no other values can reasonably
appear. Certainly untrue here.

> You can either set it to 72dpi, 96dpi, or measure your screen and set it to
> any value you like.

Measuring the screen is not precise enough. This is IMO the key argument here.

> You have assumed that a user has the physical capability to measure the
> monitor if necessary. That's an accessibility issue and must not be
> ignored.

Right. Many people don't have a ruler near the computer. How many people will
stand up, go to the next room, get a ruler, measure the screen, bring back the
ruler?
Repeat for each app that wants to know the dpi value by measurement. If the user
once measured, he can remember the dpi value and enter it in each app.

Also, if I get a value of 98, I know that it is most likely 100. Your
computation won't.

Implementation:
What's so bad about giving me the ability to enter a value? You could just turn
the read-only drop-down into a wriable drop-down combo box.
If that doesn't exist in Mozilla, shame on XUL and add a textfield to the dialog.

Gerv, if you don't want to fix it, then better reassign than marking WONTFIX.

Comment 10

[Gervase Markham [:gerv]]

> When?

Thursday.

> Measuring the screen is not precise enough. This is IMO the key argument here.

Widen the dialog to reduce the error. Given that you say many X servers use the 
wrong DPI value anyway, having it off by one or two DPI due to bad measuring is 
not a problem.

XUL does have dropdown combo boxes, but both I and mpt hate them (as I stated 
above). This UI was designed especially so we wouldn't need one. I repeat: I am 
not complicating the UI for everyone so that your highly atypical 
broken-X-server-projection-screen-user can work round his X server's brokenness.

This is a pointless argument about something trivial. I'm only sorry I can't 
de-CC myself without effort. You go fix more important bugs, and I'll go and 
revise for my exams.

Gerv

Comment 11

[Matthew T (active 1999-2002)]

Deary me. Now, it happens that iCab's resolution dialog (which I just looked at)
is very similar to ours, and it does not have a text field for direct entry of
the dpi value. However, Internet Explorer's resolution dialog (which started
this whole resolution dialog craze in the first place) *does* have such a text
field. The text field is useful for a number of reasons:
*   it allows entry of a dpi value when measurement of the display is not 
    feasible (as in tenthumbs' example);
*   it allows users to see how their manipulation of the ruler affects the dpi
    value;
*   it allows users to fine-tune their dpi value (e.g. to round 73.60 dpi down
    to 72 dpi) so as to get non-jaggy fonts.

The current resolution dialog is very sparse, and I believe adding a text field
for direct dpi entry would definitely improve usability rather than degrading
it. Reopening.

> You'll be wanting three text fields for RGB hex values in the colour picker,
> next...

There are three text fields for entering RGB hex values in the Mac OS native
colorpicker (in the `HTML Picker' panel). Since that's the way Web authors are
used to specifying colors, the inability to enter hex values for colors in
Composer is indeed a bug. :-)

Comment 12

[Matthew T (active 1999-2002)]

Reassigning to someone other than Gerv.

Comment 13

[Gervase Markham [:gerv]]

Well :-P

Your 3 points:

* this example is pathological
* Why should they care? It's not like they can say "Oops, that's come out at 
42dpi. I must be too stupid to use a ruler correctly."
* We already round the value to the nearest integer.

If you _really_ _really_ insist, I might get around to this, but not for the 
next few weeks. The X server bug is more important, for a start.

Gerv

Comment 14

[Chris McAfee]

-> gerv, cc mcafee

Comment 15

[Gervase Markham [:gerv]]

Will no-one rid me of this troublesome bug?

Gerv

Comment 16

[Kelly Price]

I'm partly affected by this bug.  Can't we just have an "advanced DPI setting"
box, as I've described in bug 109830?

Comment 17

[Jeremy M. Dolan]

Why not just add dpi to the in/cm dropdown in other... not pretty, but beats
trying to measure the dumb little line with a ruler (which, by the way, seems
slightly off anyway...I'm getting a few extra DPI when I measure that vs
calibrating the whole screen).

Comment 18

[Matthias Versen [:Matti]]

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

Comment 19

[Gili Tzabari]

I don't want to start a flamewar here or anything but Gervase your kind of 
attitude is unhealthy for two reasons:

1) You seem to think that you know what's best for the end-user. Last time I 
checked, you're a programmar, not a UI-specialist
2) You seem to have the windows-mentality of dumbing everything down. Just 
because 85% of people won't user this feature doesn't make it invalid. There is 
*strong* reasons for adding this functionality.

  This is exactly the sort of mentality that drove me right off the Windows 
platform. People who think it's smarter for a user to measure the length of a 
line off his screen using a ruler rather than enter a DPI value have to get 
their "intuitive gauge" looked at.. Furthermore, there is nothing wrong with 
adding this extra bit of functionality while keeping your ruler-measuring-trick 
around. It's not one-or-the-other; keep both!

.. Sorry for the hostility but I really needed to vent some steam about this 
issue. I don't appreciate applications that treat you like an idiot. If I 
wanted that sort of mentality I'd be using IE..

Comment 20

[Ben Bucksch (:BenB)]

Gili, luckily, this bug is now NEW, not WONTFIX. I.e. anybody can wander in any
fix it (not hard, probably also doable with PatchMaker).

Comment 21

[Matthew T (active 1999-2002)]

I think this is the best I can design while we don't have a proper ruler in the
dialog:

,------------------------------------------------------.
|::::::::::::::::: Display Resolution :::::::::::::::::|
+------------------------------------------------------+
|                                                      |
| Enter your display resolution:                       |
| [          ] dpi                                     |
|                                                      |
| |__________________________________________________| |
| |                                                  | |
| Or measure this line and enter its length:           |
| [          ] [ inches        :^]                     |
|                                                      |
|                                                      |
|                                ( Cancel ) ((  OK  )) |
`------------------------------------------------------'

Implementor should ensure the following:
*   the two text fields are the same width;
*   both text fields default to the current values (the text field in the
    current dialog does not);
*   each text field updates correctly when the other text field is changed;
*   the `Cancel' and `OK' buttons use the proper overlay so that they're
    right-aligned (currently they're centered).

Comment 22

[tenthumbs]

Yes, you must have an alternate entry method. Requiring a measurement 
implcitly requires functional hands and functional eyes which raises 
accessibility issues that you definitely do not want to be involved in.

Comment 23

[Håkan Waara]

I'm kinda working on a patch...

Comment 24

[Gili Tzabari]

Matthew's design rocks :) Just my 2 cents..

Comment 25

[Andrew Schultz]

I have a patch for this, with one unresolved issue:

If the current DPI is "System Setting", the DPI value we get is 0.  I guess we
can fall back to 96 when System Setting is selected, but it would be nice to do
this right.

in addition to mpt's suggested behavior, the "measured" value is converted when
you go between centimeters<->inches *if* the dpi is set.

Comment 26

[Andrew Schultz]

Attachment: patch

Comment 27

[Gervase Markham [:gerv]]

We shouldn't fall back on 96 for the System Setting, we should use the System
Setting :-) When that dialog returns, if there is no System Setting on that
platform, it should use whatever's defined as the default in the .properties file.

Gerv

Comment 28

[Ben Bucksch (:BenB)]

Why not just leave the 0 in the dialog? mpt will probably kill us, but the
concrete value of the current system setting is different from having System
Setting activated. The System Setting might change (X is network transparent).
Opening the dialog and immediately clicking OK should not change anything IMO.

Comment 29

[Andrew Schultz]

> Opening the dialog and immediately clicking OK should not change anything IMO.

Opening the dialog and immediately clicking Cancel DOES change the DPI to 96!

I wasn't going to mention that because it seems like another bug...  basically,
when you hit cancel, it returns -1, but the calling JS does not know what the
old value was, so it resets it to 96.

How about if "use the system setting" is set, then display "system" (or
something like that) in both boxes (dpi and size), instead of "0" and "infinity"?

Comment 30

[Andrew Schultz]

> Opening the dialog and immediately clicking OK should not change anything IMO.

If it wasn't clear from my last statement, clicking OK also (currently) changes
the setting to 96 dpi.

Comment 31

[Andrew Schultz]

Attachment: patch

use "system" as a "unit" and disable/enable the textboxes when the units are
changed.  this does not "fix" the 96dpi-on-cancel behavior.

Comment 32

[Felix Miata]

Since this function has been available on supported platforms for quite some time via about:config, maybe it's time to dispose of this.

Comment 33

[Phoenix]

The UI for this gone long ago thus making this bug obsolete, so closing it

Comment 34

[Ben Bucksch (:BenB)]

(It was valid at the time of filing, and the problem is gone, thus WORKSFORME.)