Red Hat Bugzilla – Bug 147029
RFE: system-config-printer should allow manually marking printers as "raw" queues
Last modified: 2008-08-02 19:40:32 EDT
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:
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.
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).
Oh, yes, that's true: the current situation shows an apparently queue-specific option but has a spooler-wide effect, as you point out.
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!
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.
Okay, thanks.