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)

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

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

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

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

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

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

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

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

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

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?

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

Mass-moving remaining Nav team 0.99 bugs to 1.0.

nsbeta1+ per Nav triage team

re-assigning 'several bugs at once' to morse@netscape.com.

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

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

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

adding self to cc list

See Bug 135772 for a proposed elegant resolution.

morse: Can I take this one, please ?

Roland, by all means. Thanks.

reassigning

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

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

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

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

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

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

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

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.

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

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.

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.

taking bug

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

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.

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

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

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

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 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 on attachment 103666 [details] [diff] [review] patch v1 r=dcone

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

fixed

the conversion in convertMarginInchesToUnits() and convertUnitsMarginToInches is wrong and results in a margin of 127mm i hope my first silly patch is ok.

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

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

I need to reopen to verify the Win98 issue.

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?

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.

From comment 49: Conversion problem is bug 187900.

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.

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.