VERIFIED FIXED in mozilla0.9.9



Printing: Output
17 years ago
17 years ago


(Reporter: Roland Mainz, Assigned: Roland Mainz)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 3 obsolete attachments)



17 years ago
|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
- Page orientation not supported (orientation is usually "landscape" or
"portrait", but some printer support more items here)
- Colorspace not supported (like printing "color" on a "grayscale"-only printer)

Comment 1

17 years ago
Assignee: rods → Roland.Mainz


17 years ago
Target Milestone: --- → mozilla0.9.9

Comment 2

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

Comment 3

17 years ago
Created attachment 65452 [details] [diff] [review]
Patch for 2002-01-14-08-trunk

Comment 4

17 years ago
Requesting r=/sr= ...
Keywords: patch, review

Comment 5

17 years ago


17 years ago
Blocks: 120916

Comment 6

17 years ago
+NS_ERROR_GFX_PRINTER_PAPER_SIZE_NOT_SUPPORTED=Requested paper size not supported 
by printer.
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

17 years ago
Created attachment 66796 [details] [diff] [review]
New patch for 2002-01-23-08-trunk with slightly better comments
Attachment #65452 - Attachment is obsolete: true

Comment 8

17 years ago
" 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

17 years ago
> 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

17 years ago
Created attachment 66803 [details] [diff] [review]
New patch for 2002-01-23-08-trunk with slightly 2*better comments
Attachment #66796 - Attachment is obsolete: true

Comment 11

17 years ago

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

17 years ago
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

17 years ago
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

17 years ago
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

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

17 years ago
Created 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
Attachment #66803 - Attachment is obsolete: true

Comment 16

17 years ago
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

Attachment #66822 - Flags: superreview+

Comment 17

17 years ago
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

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.


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

     [Continue]  [Cancel] 

Comment 18

17 years ago
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

17 years ago
Fix checked in, marking bug as FIXED.

Comment 20

17 years ago
Trying again to mark this one as FIXED...
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 21

17 years ago
Roland, please verify and mark verified-fixed....thanks

Comment 22

17 years ago
Roland please verify...
Sujay, at the very least you can use to verify the code
was checked in.

Comment 24

17 years ago
You need to log in before you can comment on or make changes to this bug.