150416 - Printer properties margins are limited to 0.5 in

Status: RESOLVED INVALID

(Core :: Printing: Output, defect)

Description

[Marco Franzen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.0) Gecko/20020529
BuildID:    2002052918

Print|Properties does not allow me to specify paper margins greater than 0.5
inches. 
My printer requires a bottom paper margin of 0.55 in (or actually 14.0 mm, but
that is bug 135772), so the footer of the pages prints illegible if at all.

Reproducible: Always
Steps to Reproduce:
1. File->Print...->Properties...
2. Under "Gap from edge of paper to Margin" try to enter (say 0.6) in any of the
four fields

Actual Results:  As soon as the field loses focus, the value springs to 0.5.

Expected Results:  The value you enter should be accepted and honoured when
printing.

Comment 1

[rods (gone)]

I do not see this. I can set the margin to about any value although it does seem
to get rounded. 0.55 rounded to 0.5

Comment 2

[rods (gone)]

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

Comment 3

[sujay]

verified.

Comment 4

[Matt Behrens]

I'm reopening this because this is NOT fixed, although it seems to behave a
little differently than originally described

I'm doing it right now with the Solaris 1.2.1 mozilla.org build, as well as
Debian's 1.2.1-6 from unstable.  0.6?  0.5.  1.0?  0.5.  2.0?  0.5.  

But there's another part to it.  If I tab away VERY QUICKLY, 0.55 can stay.  If
I dilly-dally with leaving focus in the box, it gets truncated to 0.5.  I can't
get 0.6 to stay no matter how quickly I tab away.  I can get 1, or 5 to stay.

Something very strange is going on inside this dialog's code.

Comment 5

[Kenneth Herron]

The limitation is built into
xpfe/global/resources/content/unix/printjoboptions.xul; see
<http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/unix/printjoboptions.xul#98>.

Comment 6

[Greg]

I am seeing somrthing very simikar in this mozilla version:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5: Desktop/LX Amethyst)
Gecko/20031016, for linux Desktop/lx update 3.
There is a slight difference because it only applies when I try to set the
header or footer margins to anything different than 0.5 and the moment after I
type the figure, say 1.0, it changes back to 0.5 even before the field loses focus. 

Comment 7

[Kenneth Herron]

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

Comment 8

[Edward]

Bug 245132 has been marked as a duplicate of this bug, and I would like to
report a fix for this, although it works with the printer referenced in bug 245132.

Changing one value in PREFS.JS:  

print.printer_PostScript/default.print_edge_bottom 

from 50 to 60, which changed the bottom margin in Print/Properties from .5
inches to .6 inches, solved the problem reported in bug 245132.

Comment 9

[Kenneth Herron]

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

Comment 10

[Felix Tiede]

I have this bug in this version: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.5) Gecko/20041219 Firefox/1.0.

Comment 12

[Rich Dougherty]

Attachment: Patch v1

This patch removes the hardcoded limit of 0.5 that's set in printjoboptions.xul
(first mentioned in comment 5). It also changes the validation so that it
occurs oninput, rather than onkeyup. This means that it is no longer possible
to avoid validation by changing focus very quickly (as mentioned in comment 4).

Some further notes (and questions, because I'm new around here):

* I removed the limit of 0.5 because it seemed arbitrary and because it was
  clearly a problem for some people - hence this bug! Would it be a good idea to
  replace it with more intelligent validation? Or is it ok, as this patch
  assumes, to remove the upper range check entirely? (Note that negative numbers
  are still correctly prevented by the validation logic.)

  For example, we could check that the entered values fit the available space.
  The available space could probably be calculated from the paper size, the page
  orientation and from the size of the margins. If I need to do something like
  this then I'd appreciate some guidance on how the validation logic should
  actually work.

* If we improve the Printer Settings validation, should we also fix some of the
  margin validation in the Page Setup dialog? I note that in this dialog I am
  able to set margins that exceed the page size (eg 1000 inch margins).

* If we decide to enforce valid input then we might also need to consider how
  we keep fields valid when other fields change. For example, changing the
  paper size could invalidate the margin values.

* There were two versions of prinjoboptions.{xul,js} in the Firefox tree:
  xpfe and toolkit. I made changes to the toolkit version as that seemed to
  be the one that Firefox uses. Does the other one need changing too? If so,
  then I can make the change easily, but how would I go about testing it?

Comment 13

[Victor Engmark]

This bug is still present in build "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11"

Comment 14

[Kenneth Herron]

The patch for bug 193001 rendered this moot. Gecko now uses the GTK printing system for its print dialogs.