Closed Bug 257381 Opened 21 years ago Closed 21 years ago

[ps] Refactor printer list logic for the postscript module

Categories

(Core :: Printing: Output, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: kherron+mozilla, Assigned: kherron+mozilla)

References

Details

Attachments

(1 file, 3 obsolete files)

Right now the logic for finding the printers supported by the postscript printing module is intertwined with the logic for initializing the print dialog. As part of generally improving the PS module's support for different kinds of printers, this logic should be moved into the PS module and accessed through an API.
Attached patch Add a printer list API (obsolete) — Splinter Review
This takes the existing logic for building the PS printer list (including the recently checked in CUPS support) and moves it into a separate class, which is stored in the gfx/src/ps directory. The class is pretty rudimentary because I'm just refactoring here; it's intended to be a foundation for future improvements. I think the only practical difference is that CUPS printers are identified as "CUPS/printername" instead of "PostScript/printername". This patch also removes an unnecessary member variable "mGlobalNumPrinters" from the device context spec global printers class.
Attachment #157364 - Flags: superreview?(mkaply)
Attachment #157364 - Flags: review?(tor)
i was planning to use nsISimpleEnumerator and have a class which joined the available enumerators. - I needed this for ps+windows or ps+beos ...
Comment on attachment 157364 [details] [diff] [review] Add a printer list API Oops, forget this patch. The print-to-pipe print job class assumes every printer name starts with "PostScript/", so that needs to be addressed.
Attachment #157364 - Attachment is obsolete: true
Attachment #157364 - Flags: superreview?(mkaply)
Attachment #157364 - Flags: review?(tor)
Attached patch More extensive patch (obsolete) — Splinter Review
This patch reorganizes the code in a different way, and adds support for printing directly through the CUPS API. A while back we added a class (stored in nsPaperPS.cpp) which had to be accessed by both the ps component and the gtk/xlib components. Because the two component libraries couldn't be linked against each other, this class is linked into the shared library built in the gfx/src directory. The current patch adds two more classes--a printer list class and a CUPS wrapper class--which are used by both ps and gtk/xlib; rather than continuing to add code to the gfx/src library, I've moved all three of these classes into a separate directory, gfx/src/psshared. In this directory we build a shared library which is linked with the ps and gtk/xlib components. This patch also adds a print job submission class for printing to CUPS printers directly through the CUPS API. Once all the other pieces were in place, this was a pretty simple addition.
Attachment #157807 - Flags: superreview?(mkaply)
Attachment #157807 - Flags: review?(roc)
This looks good, but it looks like the new files in psshared aren't included in the patch. Also, mkaply is not a super-reviewer. I can give r+sr.
> This looks good, but it looks like the new files in psshared aren't included in > the patch. I was wondering that myself. I don't see any reference to the CUPS code.
Attached patch More extensive patch v2 (obsolete) — Splinter Review
Oops, sorry about that. This one should be complete. I've left out the text of nsPaperPS.cpp and nsPaperPS.h, but they would be moved from gfx/src/ps to gfx/src/psshared as part of the checkin. In this patch I've also changed the name of the printer list class from nsPSPrinterManager to nsPSPrinterList. I'm having a hard time coming up with an appropriate name for this class.
Attachment #157807 - Attachment is obsolete: true
Comment on attachment 158029 [details] [diff] [review] More extensive patch v2 I'll just set r? for now. Roc, if you're comfortable giving r+sr that'd be great. I'd like to get this in for the next alpha if possible.
Attachment #158029 - Flags: review?(roc)
Attachment #157807 - Flags: superreview?(mkaply)
Attachment #157807 - Flags: review?(roc)
Comment on attachment 158029 [details] [diff] [review] More extensive patch v2 + struct { + const char * const symName; + void **symPtr; + } syms[] = { Make it static and outside the function, that should be smaller/faster. +#ifndef nsCUPSShim_h___ +#include "nsCUPSShim.h" +#endif I wouldn't bother with this sort of thing. > static enum PrinterType Can't you elide 'enum'? + if (0 == memcmp(aName, NS_POSTSCRIPT_DRIVER_NAME, NS_POSTSCRIPT_DRIVER_NAME_LEN)) + pt=kTypePS; + else if (0 == memcmp(aName, NS_CUPS_PRINTER, NS_CUPS_PRINTER_LEN)) These aren't really safe. They might read beyond the end of the string and cause a fault. Actually I think it would best if you just had the nsPSPrinterList::GetPrinterType(const nsACString& aName) version and used our string methods. + * @param aList Upon return, this is populated with the list of Please mention that these are UTF8 strings (also in GetPrinterType).
Attached patch Updated patchSplinter Review
This should address the review comments.
Attachment #158029 - Attachment is obsolete: true
Attachment #158071 - Flags: review?(roc)
Attachment #158029 - Flags: review?(roc)
This is checked in and (mostly) cleared tinderbox. Resolving FIXED.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
is there a reason why CUPS is not tried by default? 1_7_BRANCH and AVIARY_BRANCH are using CUPS by default (at least on Linux) and 1.8 uses a pref which isn't set anywhere. How about adding the pref and enable it by default?
Depends on: 573039
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: