118954 - Printing page setup uses inches for margins in a metric world

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Stefan Seifert]

In printing page setup you can specify margins, but only in inches. This is way
unhandy if you live in this little metric part of the world here. The dialog
should adapt to the OS settings and support cm or mm as unit.

I think the issue about standard page size is reported elsewhere (should be A4 here)

Comment 1

[Alex Bishop]

I can't find any duplicates (but it wouldn't surprise me if one turned up) so 
I'm marking this NEW.

Comment 2

[rods (gone)]

Peter, I see this as a UI issue, not as a back end issue.

Comment 3

[Peter Trudelle]

Yup, support for metric input is very important. ->law

Comment 4

[R.K.Aa.]

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

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 6

[Bill Law]

Blocker bug 113727 fixed and there is support for responding properly to the 
setting of nsIPrintOptions::paperSizeUnit.

Comment 7

[Matthias Versen [:Matti]]

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

Comment 8

[Matthias Versen [:Matti]]

reopening

I still get "inches" in Page setup.
Build 20020305.., win2k SP2 German, Epson Stylus Color 740 (german driver).

Comment 9

[Stefan Seifert]

confirming on Linux/2002030518. I guess only the backend changed but the
frontend has just another layout but the same bug.

Comment 10

[Bill Law]

Not quite.  The front-end has support for displaying margins in millimeters. 
The backend never reports that the page unit size is millimeters.  I'm not sure
how we're supposed to deduce that.  Worst case, we'll have to add a radio button
for the user to tell us.

Rod, I presume that the margin values specified in nsIPrintSettings are always
interpreted as inches by the backend code?  And the values stored in the user
prefs are always inches?

Comment 11

[Peter Lairo]

> And the values stored in the user prefs are always inches?

Hopefully not. Wouldn't storing them in SI units ("mm") be better in the long term?

Comment 12

[Peter Trudelle]

Mass-moving remaining Nav team 0.99 bugs to 1.0.

Comment 13

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 14

[Peter Trudelle]

re-assigning 'several bugs at once' to [e-mail].

Comment 15

[Jaime Rodriguez, Jr.]

ADT3 per ADT triage. We should be able to localize, but we wouldn't hold ship
for this one.

Comment 16

[Peter Lairo]

If localization shoudn't make 1.0, then at a *minimum* the "fixed" units should
be changed to metric (cm) by 1.0.

Comment 17

[R.K.Aa.]

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

Comment 18

[Ian Pottinger]

adding self to cc list

Comment 19

[Markus Kuhn]

See Bug 135772 for a proposed elegant resolution.

Comment 20

[Roland Mainz]

morse:
Can I take this one, please ?

Comment 21

[Stephen P. Morse]

Roland, by all means.  Thanks.

Comment 22

[Stephen P. Morse]

reassigning

Comment 23

[Roland Mainz]

1. If there is no argument again this I'd like to mark this bug as DUPlicate of
bug 135772 ("US-centric printer interface").

2. AFAIK (please correct me if I am wrong) we should make the unit type depend
on the type of paper used and not make it depend on the locale.
For example: "US Letter" should use "inches" as unit and "ISO A4" should use
millimeters ...

Comment 24

[Markus Kuhn]

The by far best and simplest approach is to turn everything into millimeters.

The metric system has been been officially recognized in the United States since
Congress passed the Metric Conversion Act of 1975 and it was declared to be the
preferred system of measurement by US Congress in 1988 (Public Law 100-418). We
should respect these US legal requirements to the letter! US Letter paper has
according to American National Standard ANSI X3.151-1987 an exact size of 216 x
279 mm.

I suggest to just use millimeters all the time. Before making units switchable,
wait first until someone from the US protest and brings good arguments for such
functionality. They are perfectly familiar with millimeters by now and shouldn't
need decimal-inch based margins.

[Canada is metric, but still uses US Letter paper, therefore you shouldn't bind
paper size and measurement system together anyway. The country name in the
locale as suggested in Bug 135772 would be the proper way of doing things *IF*
millimeters were unacceptable for US users. I hope this will not be necessary.
The 9 mm handgun and 35 mm film are far too popular items in the US to support
any notion that they can't handle millimeters ...

Sources:

http://www.usmetric.org/
http://www.cl.cam.ac.uk/~mgk25/iso-paper.html

Comment 25

[Peter Lairo]

> I suggest to just use millimeters all the time.

Please NO. At the scale between 1 cm and 1 m, most metric users think in terms
of *centimeters* (cm). If you use millimeters (mm) for anything above 10 mm
(1cm), then most metric users will mentally have to convert it to centimeters
anyhow. Nobody can intuitively "grasp" how large 290 mm are.

I therefore sugget to use *cm* for margins (2.5 cm) and paper sizes (A4: 21 x
29.7 cm).

Let's not again have the US go off on a tangent using whacko units, while
ignoring the decades of experience and advice of those who know better. ;)

Comment 26

[Markus Kuhn]

I'm afraid, disagree with Peter Lairo on his recommendation for centimeters. It
is well-established practice in Europe today to do everything related to
typography in millimeters (unless US software still forces you us to use silly
points, pica, inches, dpi, etc. with conversion factors that hardly anyone
remembers). Every secretary in a word processing course learns how to set
left/right margings to 20 mm and top/bottom margins to 15 mm. The difference
between cm and mm is just a comma shift, so no mental arithmetic is necessary,
but agreeing to use only one of them (which has already happened) simplifies
life and reduces misunderstandings, so we should stick to established practice.
Sure, both units are equally intuitive and 100 mm and 10 cm look like the exact
same thing to me. But all the standards are written in mm (e.g., look at DIN
5008 Appendix B/C and DIN 16507-2 on layout and typography), technical drawings
are exclusively labeled in mm. Using only one single unit allows you to drop or
ignore the unit name entirely and avoids confusion and ambiguity. The cm is
vanishing in many fields. Paper formats are most definitely exclusively labeled
in mm, not in cm. You won't find in any stationary shop around here 21x29.7 cm
paper. It is all 210x297 mm! Look, even Americans don't fire 0.9 cm bullets or
make 3.5 cm films. They use 120 mm CD-ROMs (and, without knowing, 90 mm floppy
disks :) just like the rest of us ...

Sources:

http://www.cl.cam.ac.uk/~mgk25/volatile/din-16507-2.pdf (in German)
http://www.cl.cam.ac.uk/~mgk25/metric-typo.html

Comment 27

[Peter Lairo]

> Every secretary ... _learns_ how to set left/right margings to 20 mm

Every secretary I have _asked_ about margins has always answered in *cm*. Ask
anyone how big an A$ page is - _all_ will answer in *cm*. We should be careful
to differentiate between how standards are _written_ (by engineers) and how they
are _used_ by regular people.

Please pleae do not even consider dropping the unit _name_. We don't want to
drift into ambiguity (not everyone will know that someone wrongly suggested
using only one unit - regardles of what the appropriate real-world scale would be).

PS. We're designing a browser (cm), not building bullets (mm). ;)

PPS. "mm" are used when precision at *that* scale is needed (bulles, film,
floppies). The unit chosen should match the scale it is describing.

Comment 28

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 29

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 30

[Karl Ove Hufthammer]

FWIW, the Norwegian version of MS Office uses 'cm'. *If* 'mm' is used, it should at least be localizable, so that I can change it to 'cm' for the Norwegian localization.

Comment 31

[Josh Birnbaum]

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

Comment 32

[Vaclav Dvorak]

This is just nitpicking, but I vote for mm, not cm. And if you ask me about A4,
I will most certainly answer 210x297, so Peter's statement about _all_ people is
false. :-)

For the record, Czech localizes MS Word uses cm for page margins, cm for custom
page size, but mm in the names of built-in non-US paper sizes. The HP LaserJet
driver in Czech Win98 uses mm for paper size.

My proposal: mm should be used for paper size and cm for the margins, by
default, but the user should be able to use any supported unit by simply
entering its name. So the input box would initially contain e.g. "2 cm" but the
user would be free to enter "0.7874 in" instead if he so desires. That's how it
works in MS Word, too.

Comment 33

[rods (gone)]

Attachment: patch v1

This patch fixes the XP Page Setup Dialog and fixes Windows. Bug 175879 covers
the Linux specific issues.

Basically, the Page Setup Dialog was only written to change the title of the
group box but it was handling the conversion of the PS margin values from
inches to millimeters. It does that now.

On Window it wasn't setting the units correctly into the PS when the page size
was defined in metric units. That is now fixed.

Comment 34

[rods (gone)]

taking bug 

Comment 35

[Roland Mainz]

rods:
What about switching the windows code over to using |mPaperName| instead of
messing with the page's width/height/unit ?

Comment 36

[rods (gone)]

roland:
Since we are still discussing the papername issue. I would still like to get
this in. This patch will make it work on Windows for all our non-US paper size
users. SO as discuss Bug 175879 we can talk about paper size.

Comment 37

[Gintautas Grigas]

There is additional conflict with international standards: point (instead of
comma) is used as decimal separator in specification of margins. 

Comment 38

[Achim Kalwa]

Is the patch already applied in 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b; MultiZilla v1.1.31)
Gecko/20021104?

If yes, then there is still something going wrong: 
If I enter 20mm for top,bottom,left and right; the preview/printout is empty.
Setting margins to 0.5 mm leads to a 21 mm margin if print; setting it to 1.0 mm
results in 33 mm margin.

(Win 2k, Kyocera FS1750, paper size ISO-A4, portrait)

Achim

Comment 39

[rods (gone)]

This patch has not gone in, this bug would be marked "fixed" if it had

Comment 40

[Alec Flett]

Comment on attachment 103666 [details] [diff] [review]
patch v1

please add spaces before/after the ? and : characters in the SetPaperSizeUnit
calls and wrap as necessary - that line is totally unreadable.

aside from that, the code looks fine. sr=alecf

Comment 41

[Alec Flett]

Comment on attachment 103666 [details] [diff] [review]
patch v1

please add spaces before/after the ? and : characters in the SetPaperSizeUnit
calls and wrap as necessary - that line is totally unreadable.

aside from that, the code looks fine. sr=alecf

Comment 42

[dcone (gone)]

Comment on attachment 103666 [details] [diff] [review]
patch v1

r=dcone

Comment 43

[Craig]

Regarding comment #37, that should be minor. If Mozilla gets the local
measurement system from the operating system, it should obtain the local decimal
symbol from the same place.

Regarding paper sizes and margins, I've only ever seen A4 anywhere as 210x297
mm. Margins are more commonly in mm in my experience and are easier in mm
because it's easier to type "15" than "1.5".

Comment 44

[rods (gone)]

fixed

Comment 45

[Corrado Berti]

Attachment: fix conversion error

the conversion in  convertMarginInchesToUnits() and convertUnitsMarginToInches 

is wrong and results in a margin of 127mm 



i hope my first silly patch is ok.

Comment 46

[Koike Kazuhiko]

2002111704-trunk/Linux and 2002111508-trunk/Win98 still use inches.

Comment 47

[rods (gone)]

It doesn't work on Linux because of Bug 175879, re-closing this bug.

Comment 48

[rods (gone)]

I need to reopen to verify the Win98 issue.

Comment 49

[Craig]

If you set a margin to, say, 5 mm, Mozilla stores it as "0.196528" in prefs.js.
Taking that number in inches and converting to mm gives about 4.99, but Mozilla
displays it as 4.9, not 5.0.

Is this rounding bug going to need a new bug report, or will it be fixed as part
of this one?

Comment 50

[Alex Hosking]

Is this even leagal in the UK?

Contry to what most americans(anoyingly)think we in the UK know Imperial
mesurements just as well as you, but I think this need a pref.

Comment 51

[Hideo Oshima]

From comment 49:
Conversion problem is bug 187900.

Comment 52

[Moritz Moeller-Herrmann]

Not fixed for the Debian linux version in 1.5. What is holding this back? There
are settings for this in Linux and I guess in other OS, too. Hardly anyone knows
what inches are outside the USA.

Comment 53

[Kenneth Herron]

Bug 175879 has is resolved fixed. With the PS printing module, when an ISO paper
size is selected under File->Print->Properties, the page setup margins
(File->Page Setup->Margins & Header/Footer) will appear in millimeters.

Resolving fixed.