270025 - [ps] Detect native AIX print queues

Status: RESOLVED WONTFIX

(Core :: Printing: Output, defect)

Description

[Philip K. Warren]

Recently, support was added to Mozilla to detect CUPS print queues. I would like
to add similar support for detecting AIX print queues which are defined in the
AIX /etc/qconfig configuration file.

Comment 1

[Philip K. Warren]

Attachment: Patch v1

Comment 2

[Kenneth Herron]

Comment on attachment 166021 [details] [diff] [review]
Patch v1

>+/**
>+ * This reads the list of configured print queues on an AIX system by
>+ * parsing the /etc/qconfig file, which is in stanza format. All stanzas
>+ * with a device attribute are print queues.
>+ *
>+ * Returns PR_TRUE if printers were found, PR_FALSE otherwise.
>+ */
>+PRBool
>+ReadAIXPrinters(nsCStringArray& aList)
>+{
>+    FILE *fp = fopen("/etc/qconfig", "r");

To start with, this function should be declared static. And it'd be useful to
include some example text from /etc/qconfig or a description of the important
lines, in case someone ever has to rewrite any of this code.


>+            if (name.EqualsLiteral("device") && !value.IsEmpty()) {
>+                nsCAutoString fullName(NS_POSTSCRIPT_DRIVER_NAME);
>+                fullName.Append(queue);

I'm not sure I like the idea of tagging these with "PostScript". At a minimum,
if the user specified a printer list through the environment variable or the
pref, then we could end up with the exact same printer listed twice. This is
likely to be reported as a bug.

I've been thinking about how to support lpr/lp printers with autodetection. The
scheme I have in mind for them is to add each printer as "LPR/printername" or
"LP/printername". This way, if the user sees "CUPS/foo", "LPR/foo", and
"PostScript/foo" he's more likely to understand what is going on. Furthermore,
we could handle these printers differently. If we know a printer is an lpr
printer, we could construct an lpr command for it instead of just running an
opaque command. Even if you don't want to develop an aix-specific print job
class, tagging these printers differently would make it clearer to the user
where they came from.

If you'd rather continue tagging these printers as PostScript, then this logic
should be integrated with the existing logic for
MOZILLA_POSTSCRIPT_PRINTER_LIST and the pref print.printer_list.

Finally, as a matter of policy I'm not sure we want to remove
PostScript/default at this point. The user may have an existing setup with a
non-default command configured, such as piping the print job into kprinter.
More generally there should always be a printer in the list with a submission
command the user can edit. I realize the printers from qconfig would have that
property here, but I'm thinking of the design policy.

Comment 3

[Philip K. Warren]

(In reply to comment #2)
> To start with, this function should be declared static. And it'd be useful to
> include some example text from /etc/qconfig or a description of the important
> lines, in case someone ever has to rewrite any of this code.

Ok - I will do both of these.

> I'm not sure I like the idea of tagging these with "PostScript". At a minimum,
> if the user specified a printer list through the environment variable or the
> pref, then we could end up with the exact same printer listed twice. This is
> likely to be reported as a bug.

I think I'd prefer to keep them listed as "PostScript" as long as they don't
have any special properties which differentiate the queues from any other queues
we use on the system. I think if a user sees both LPR/queue and
PostScript/queue, I don't think they would know how they differ from one another. 

> If you'd rather continue tagging these printers as PostScript, then this logic
> should be integrated with the existing logic for
> MOZILLA_POSTSCRIPT_PRINTER_LIST and the pref print.printer_list.

Ok - good point.

> Finally, as a matter of policy I'm not sure we want to remove
> PostScript/default at this point. The user may have an existing setup with a
> non-default command configured, such as piping the print job into kprinter.
> More generally there should always be a printer in the list with a submission
> command the user can edit. I realize the printers from qconfig would have that
> property here, but I'm thinking of the design policy.

For me, having the PostScript/default queue is quite confusing, especially if
one of the printers set up on the system is already designated the default
queue. If you look at the printer dialog on Windows for example, the only items
listed are the printers set up on the system. Would having a non-default print
command break if the printer name is a real queue instead of 'default'?

Comment 4

[Kenneth Herron]

(In reply to comment #3)
> For me, having the PostScript/default queue is quite confusing, especially if
> one of the printers set up on the system is already designated the default
> queue. If you look at the printer dialog on Windows for example, the only items
> listed are the printers set up on the system. Would having a non-default print
> command break if the printer name is a real queue instead of 'default'?

Phil,

Sorry it has taken me so long to respond. As far as I know, the only practical
issue with leaving PostScript/default out of the printer list is that the user
may have set a special print command for that destination and may be unhappy
that it's no longer available. We could try it your way and see if anyone complains.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jwatt, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 6

[Mike Kaply [:mkaply]]

There is no more AIX Mozilla as far as I know.