Bug 147029

Summary:	RFE: system-config-printer should allow manually marking printers as "raw" queues
Product:	[Fedora] Fedora	Reporter:	Chris Bagwell <chris>
Component:	system-config-printer	Assignee:	Tim Waugh <twaugh>
Status:	CLOSED CANTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	mattdm
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-07-11 16:11:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Bagwell 2005-02-03 20:47:08 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; rv:1.7.3) Gecko/20041007
Firefox/0.10.1

Description of problem:
This is a request to enhance the system-config-printer program so that
it is more obvious to the user how to get remote printing to always work.

I have set up an Epson R300 printer using system-config-printer and I
have enabled it to be shared by others.  If I go to a remote Linux PC,
I can automatically see and print to this printer great (using the IPP
feature of CUPS).

Under windows, I must manually set up the IPP URI and install Epson's
drivers for this printer.  This almost gets it working except cups log
files talk about not knowing application/octet-stream was.  Searches
on the internet point out that you need to uncomment some lines in
/etc/cups/mime.convs and /etc/cups/mime.types.  

Modifying those files gets the single queue working for both
Postscript and RAW epson files (without using the -oraw flag which
isn't an option under windows).

There is probably though were system-config-printer will often revert
the changes you make to /etc/cups/mime.types.  After browsing the
system-config-printer source code and doing some bugzilla surfing (Bug
107061 and 133475) I see the work arounds.  I could create an
additional "raw" queue that would cause system-config-printers to be
the one that uncomments the "applicaton/octet-stream".

A better solution, I think, is adding a new option to the "Drivers
Option" tab in "Edit a print queue" dialog that says something like
"Allow Raw Data" (the option would be similar to the "Convert Text to
Postscript").

This new option would be used in addition to the "raw queue"
knownledge when uncommenting the application/octet-stream line.

Having one queue for 1 printer is pretty standard operation... Its
also more likely that users will browse the "Driver options" tab when
trying to get remote printing working then them finding out that the
solution is to create a second and unused "raw" queue.


Version-Release number of selected component (if applicable):
system-config-printer-0.6.116.1-1

How reproducible:
Always

Steps to Reproduce:
1. Create non-raw queue
2. Hand modify /etc/cups/mime.types application/octet-stream
3. Edit the non-raw-queue and mime.types is reverted.
    

Additional info:

Comment 1 Tim Waugh 2005-03-30 15:16:50 UTC

The trouble is that "Allow Raw data" is not a per-queue option, but a
spooler-wide one.  As you can tell actually: the implementation would be to
adjust the global mime.types file.

So it's not actually so clear where this option should go.

Comment 2 Chris Bagwell 2005-04-10 21:00:16 UTC

I also debated on that while writing this RFE.  I didn't debate on it to hard
because the current trigger to modify the mime.types is equally broken... If you
have one raw queue, we really shouldn't be enabling this for all queues.  But
this is more an upstream CUPS issue.

Anyways, it would be nice to have a spooler-wide menu option in
system-config-printer and it could go there.  The "Sharing..." menu option is
the current closest thing.  Matter of fact the first line in the "Sharing
properites" screen does say "These settings are system-wide".  So perhaps it is
as simply as a new checkbox on that screen to "Allow Raw Data".

I'm not sure thats quite a easy to code up though (there was already a per-queue
RAW flag that would have caused mime.types to be updated... I don't remember a
system-wide flag or how easy it is to add system wide flags).

Comment 3 Tim Waugh 2005-04-19 15:01:42 UTC

Oh, yes, that's true: the current situation shows an apparently queue-specific
option but has a spooler-wide effect, as you point out.

Comment 4 Matthew Miller 2006-07-10 22:17:39 UTC

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 5 Chris Bagwell 2006-07-11 11:38:32 UTC

This is not a bug and so can be closed for FC3.

Also, as of FC5+updates (newer version of CUPS), the RFE can not be supported as
far as I can tell.  For some reason in newer cups, when a windows machine sends
a mime type of application/octet-stream CUPS says its an unknown type (even
though cups/mime.types and cups/mime.conf have it listed) and will not accept
the windows print.  The only solution now is to create a RAW queue and specify
that as the print queue from a windows box. 

So this RFE for system-config-printer can no longer be supported in FC5 or
beyond unless CUPS changes.

Comment 6 Matthew Miller 2006-07-11 16:11:50 UTC

Okay, thanks.