|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
Assignee: rods → Roland.Mainz
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
NS_ERROR_GFX_PRINTER_TOO_MANY_COPIES is anoth nice idea (currrently we limit the number of copies to 999... ) ... :)
Requesting r=/sr= ...
Keywords: patch, review
+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.
Created attachment 66796 [details] [diff] [review] New patch for 2002-01-23-08-trunk with slightly better comments
Attachment #65452 - Attachment is obsolete: true
" 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...
> 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" ...
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
>- 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.
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
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).
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.
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 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
Attachment #66822 - Flags: superreview+
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]
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.
Fix checked in, marking bug as FIXED.
Trying again to mark this one as FIXED...
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Roland, please verify and mark verified-fixed....thanks
Roland please verify...
Sujay, at the very least you can use http://lxr.mozilla.org to verify the code was checked in.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.