120221 - Make |NS_ERROR_GFX_PRINTER_INVALID_ATTRIBUTE| more specific

Status: VERIFIED FIXED

(Core :: Printing: Output, enhancement)

Description

[Roland Mainz]

|NS_ERROR_GFX_PRINTER_INVALID_ATTRIBUTE| is too generic for some platforms.

I suggest to implement the following additional error codes:
- Given paper size not supported by printer
NS_ERROR_GFX_PRINTER_PAPER_SIZE_NOT_SUPPORTED
- Page orientation not supported (orientation is usually "landscape" or
"portrait", but some printer support more items here)
NS_ERROR_GFX_PRINTER_ORIENTATION_NOT_SUPPORTED
- Colorspace not supported (like printing "color" on a "grayscale"-only printer)
NS_ERROR_GFX_PRINTER_COLORSPACE_NOT_SUPPORTED

Comment 1

[Roland Mainz]

Taking...

Comment 2

[Roland Mainz]

NS_ERROR_GFX_PRINTER_TOO_MANY_COPIES is anoth nice idea (currrently we limit the
number of copies to 999... ) ... :)

Comment 3

[Roland Mainz]

Attachment: Patch for 2002-01-14-08-trunk

Comment 4

[Roland Mainz]

Requesting r=/sr= ...

Comment 5

[rods (gone)]

r=rods

Comment 6

[Simon Fraser [no longer active]]

+NS_ERROR_GFX_PRINTER_PAPER_SIZE_NOT_SUPPORTED=Requested paper size not supported 
by printer.
+NS_ERROR_GFX_PRINTER_ORIENTATION_NOT_SUPPORTED=Requested page orientation not 
supported by printer.
+NS_ERROR_GFX_PRINTER_COLORSPACE_NOT_SUPPORTED=Requested colorspace not supported 
by printer.
+NS_ERROR_GFX_PRINTER_TOO_MANY_COPIES=Too many job copies requested.

I don't think these strings are suitable for end-user consumption. For starters, 
they should be complete sentences ("The print job could not be completed, because 
the page orientation you specified is not supported by your printer." etc.) They 
should be run by UI folks too.

Comment 7

[Roland Mainz]

Attachment: New patch for 2002-01-23-08-trunk with slightly better comments

Comment 8

[Simon Fraser [no longer active]]

" The colorspace you specified"
Users won't know what a colorspace is. Try something like "..because you 
requested color printing, but your printer only supports grayscale" or somesuch.
I also prefer one sentence instead of two:
There was a problem printing because...

Comment 9

[Roland Mainz]

> Users won't know what a colorspace is. Try something like "..because you 
> requested color printing, but your printer only supports grayscale" or 
> somesuch.

Unfortunately this can be anything.
Just some nice examples:
Grayscale on B/W-only printer,
Color on Grayscale-only printer,
Color on B/W-only printer,
wrong color (for specical devices which can be accessed like a printer but uses
different trays for each of the R-, G-, B-, K-guns)

The only catch-all term I can imagine is "wrong color" or "wrong colorspace" ...

Comment 10

[Roland Mainz]

Attachment: New patch for 2002-01-23-08-trunk with slightly 2*better comments

Comment 11

[jag (Peter Annema)]

>-     
NS_ERROR_TO_LOCALIZED_PRINT_ERROR_MSG(NS_ERROR_GFX_PRINTER_PRINT_WHILE_PREVIEW)
>+     
NS_ERROR_TO_LOCALIZED_PRINT_ERROR_MSG(NS_ERROR_GFX_PRINTER_PRINT_WHILE_PREVIEW)

Nothing changed there, just adding whitespace at the end, please fix that.

No need to attach a new patch if smfr is happy with the wording as is, just make
sure that whoever checks this in fixes that.

Comment 12

[Simon Fraser [no longer active]]

How about "because the print job requires color capabilities that your printer 
does not support."

+NS_ERROR_GFX_PRINTER_TOO_MANY_COPIES=There was a problem printing because you 
requested too many copies.

Tell them how many is too many. If 999 is the max, say that. Of course, our UI 
should never allow the user to enter a number larger than that anyway.

Fix those, and sr=sfraser

Comment 13

[marlon bishop]

correct me if i am wrong, but isn't this only a case for the non-native, XUL
print dialog? I thought a print dialog should query the printer for these
functions and display the proper dialog before allowing a circumstance for any
of these errors.  Therefore this would only be allowed for non standard/linux
cases or on systems where no inherent print resouces are provided.

generally, i don't think a system should actually notify a user on some of these
conditions.  for example, printing color on a B&W printer, or any sort of
mismatch of colorspace, it is customary to assume the user either understands,
or the outcome isn't of significance to warrant explicitly alerting a user. The
same goes for missing printer fonts, etc; we generally try to make the best with
what resources the system has, and assume knows things like whether or not they
have a color printer. (unless the dialog involves directly manipulating these
functions, in which we shouldn't be lying by having them appear at all)

however, the print orientation (or print paper) condition would be valuable to
convey if it was left in a previously changed state and saved that way. 
however, if we offer no such explicit saving of state globally, or we revert
back to default for each new print job (which we should),  then that alert would
be irrelevant. Can't we safely assume the default orientation is already
printable by virtue of the system printer properties? also, when would a printer
have difficulty printing in landscape? most printers circa 1986, should be able
to print both landscape and portrait.

if a print size isn't supported, then it should not be shown in the print dialog
as available.


this may be a seperate point, but i am wondering, if we should offer a message
which announces that the content we are attempting to print is larger than the
currently selected print space and will be cropped, "would you like to proceed?"
 (a' la adobe photoshop)  this would be to prevent users from mistakenly
printing out unruly content with large tables for example. This would be
immensely helpful, since we don't currently have a simple "print to fit"
feature, helping the user determine that the content extends beyond print space
(suggestion to go back to print preview and scale it down).   

Comment 14

[Roland Mainz]

marlon:
We're working on extending the print dialog system (which is much hard work
because we have to change all platforms at once if we change API things) - but
these error codes provide a _quick_ solution (this crap is harassing me (at
least) since a _YEAR_ !!) for platforms which suffer from the
'|NS_ERROR_GFX_PRINTER_INVALID_ATTRIBUTE| is too generic'-issue.

I agree with you that this should be catched at the print dialog. But the
current print dialog does not offer this functionality yet - and I'd like to get
at least a working feedback system using these error codes and their matching
error messages in the 0.9.9 milestone.

Comment 15

[Roland Mainz]

Attachment: New patch for 2002-01-23-08-trunk with slightly 2*better comments per jag's and smfr's comments

Comment 16

[Simon Fraser [no longer active]]

Comment on attachment 66822 [details] [diff] [review]
New patch for 2002-01-23-08-trunk with slightly 2*better comments per jag's and smfr's comments

sr=sfraser

Comment 17

[marlon bishop]

oh ok, sorry i didn't understand the small scope of this patch.   in general,
when making an error message - provide users with a non-technical message,
followed by a suggestion on how to correct the problem, or provide a next best
alternative.

for example-

alert: This print job contains color information which the selected printer
could not handle.  Try selecting a color printer, or choose "grayscale" from the
print dialog.

or

alert: This print job contains color information which the selected printer
could not handle.  Would you like to continue by printing this document in
grayscale?

     [Continue]  [Cancel] 

Comment 18

[Roland Mainz]

marlon:
This is not possible with the current print error dialog system (but again,
we're working on it :) - it only reacts on "numeric" error codes. And we cannot
make the error codes specific enougth to provide such a context information -
nor does the current design allow the transmission of such context information
(I wish we could use C++ exceptions instead of the crappy COM error code system)
in another way (which is fun...).
And we cannot just add more NS_ERROR_GFX_PRINTER_*-codes because the number of
possible combinations is far higher than we have available error codes (and that
would end in a nightmare for the localisation people) - and I doubt we can
really catch all possibilities which are out there.

Comment 19

[Roland Mainz]

Fix checked in, marking bug as FIXED.

Comment 20

[Roland Mainz]

Trying again to mark this one as FIXED...

Comment 21

[sujay]

Roland, please verify and mark verified-fixed....thanks

Comment 22

[sujay]

Roland please verify...

Comment 23

[[e-mail] (gone - use [e-mail] instead)]

Sujay, at the very least you can use http://lxr.mozilla.org to verify the code
was checked in.

Comment 24

[Roland Mainz]

Verified.