Jack Byers byersj@hotmail.com Philip Prindeville wrote: Tim Waugh wrote: Anne Wilson wrote: ......
So what makes it raw? I was looking at the man pages for "lpoptions", and "lpadmin", "printers.conf" and "cups.conf", and didn't see anything... went onto the http://localhost:631/ web page and didn't see anything...
I used the cups interface at localhost:631 to add a new printer and 'raw' was one of the options. Unfortunately that hasn't got me anywhere with my XP to FC4 printing problem, as the XP laptop is still sending the wrong output :-( Anne
----
something very close to the following should allow seamless printing from winxp on your lan to printer on your fedora linux system
I got all of this from carla schroder book linux cookbook ch 14 that ch 14 at one point was a freebie on the net...
[root@bootp byers]# cat /etc/cups/cupsd.conf #see carla schroder linux cookbook p 246-249
LogLevel info Port 631 <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.2.* </Location> BrowseAddress 192.168.2.255
<Location /admin> AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location>
ServerName 192.168.2.8 [root@bootp byers]#
then # /sbin/service cups restart
you shouldnt need to do anything re "raw"... configure the printer on the cups interface localhost:631 on your linux host
that cups restart will broadcast your printer to your lan this is enough to serve all other linux clients on your lan, also any macs on osx
from winxp box you need a couple extra steps install TCP/IP Print services from xxxx/Other Network File and Print Services then "Add Printer wizard" add the printer URI like this example:
http://192.168.2.8:631/printers/hp22ufc that /printers/ is necessary, a convention used by cups
disclaimer: I know almost zilch about Windows I did manage using these instructions to get an old w98 box printing to my linux box last march just in time to print out forms from my w98 TaxCut. w98, for me at least, was a much tougher nut to crack; I needed a lot of extra w98 steps.... which idont have available right now. the xp instructions above are supposed to be all you need for xp.
hth Jack
_________________________________________________________________ Try Search Survival Kits: Fix up your home and better handle your cash with Live Search! http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loca...
On Monday 13 November 2006 22:04, Jack Byers wrote:
something very close to the following should allow seamless printing from winxp on your lan to printer on your fedora linux system
I got all of this from carla schroder book linux cookbook ch 14 that ch 14 at one point was a freebie on the net...
[root@bootp byers]# cat /etc/cups/cupsd.conf #see carla schroder linux cookbook p 246-249
LogLevel info Port 631
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.2.* </Location> BrowseAddress 192.168.2.255
<Location /admin> AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1
</Location>
ServerName 192.168.2.8 [root@bootp byers]#
I had pretty well all of that set already. I think the only difference was that I have 'Allow from @local' as well.
then # /sbin/service cups restart
you shouldnt need to do anything re "raw"... configure the printer on the cups interface localhost:631 on your linux host
that cups restart will broadcast your printer to your lan this is enough to serve all other linux clients on your lan, also any macs on osx
from winxp box you need a couple extra steps install TCP/IP Print services from xxxx/Other Network File and Print Services
I'm not sure what you mean by this. I have File & Print Services enabled, TCP/IP configured and NETBIOS disabled. I don't recognise your description?
then "Add Printer wizard" add the printer URI like this example:
http://192.168.2.8:631/printers/hp22ufc that /printers/ is necessary, a convention used by cups
disclaimer: I know almost zilch about Windows I did manage using these instructions to get an old w98 box printing to my linux box last march just in time to print out forms from my w98 TaxCut. w98, for me at least, was a much tougher nut to crack; I needed a lot of extra w98 steps.... which idont have available right now. the xp instructions above are supposed to be all you need for xp.
The annoying thing is that I used to have this set up and working, both on XP and win98 boxes. Like washing detergents, the 'new and improved' often turns out not to be :-)
Anne
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Tim. */
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Ah - you didn't say that last bit, before :-) I made it in cups config. I'll try s-c-p. Do I need to do anything on the XP laptop?
Anne
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Oh - and the server is FC4. Does that make any difference?
Anne
On Tue, 2006-11-14 at 10:32 +0000, Anne Wilson wrote:
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Oh - and the server is FC4. Does that make any difference?
No, no difference as far as system-config-printer and raw queues goes.
Fedora Core 6, you'll be glad to hear, doesn't need you to do any of this.
Tim. */
On Tuesday 14 November 2006 11:03, Tim Waugh wrote:
On Tue, 2006-11-14 at 10:32 +0000, Anne Wilson wrote:
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Oh - and the server is FC4. Does that make any difference?
No, no difference as far as system-config-printer and raw queues goes.
Tim, I can't see how to do it in s-c-p. The only queue types I am offered are
Locally-connected Networked CUPS (IPP) Networked UNIX (LPD) Networked Windows (SMB) Networked Novell (NCP) Networked JetDirect
If I select Locally-connected it goes on to select the HP printer driver, then says it is about to create the queue. I don't see any mention of raw in any of the screens.
Fedora Core 6, you'll be glad to hear, doesn't need you to do any of this.
Updating from FC4 is not advised, and I wouldn't argue. For the moment I just can't face the amount of work to get everything working on that box again. I've been working on this box for 2 weeks, and am only now feeling that most of the essentials are ironed out. I know there are some things that I haven't tested yet, too.
I'll get to upgrading the server eventually, but not yet.
Anne
Anne Wilson kirjoitti viestissään (lähetysaika tiistai, 14. marraskuuta 2006 13:51):
If I select Locally-connected it goes on to select the HP printer driver,
You must override the selection of the HP driver and choose the raw driver instead.
On Tuesday 14 November 2006 12:13, Markku Kolkka wrote:
Anne Wilson kirjoitti viestissään (lähetysaika tiistai, 14.
marraskuuta 2006 13:51):
If I select Locally-connected it goes on to select the HP printer driver,
You must override the selection of the HP driver and choose the raw driver instead.
Thanks, Markku. It's not altogether self-evident, but for the sake of the archives, from that page it needs Printer Manufacturer set to Generic, and that's where you get the option to set a raw queue.
It's a bit basic - no duplex, no 2-up printing, but at least it prints.
Anne
On Tue, 2006-11-14 at 12:30 +0000, Anne Wilson wrote:
It's a bit basic - no duplex, no 2-up printing, but at least it prints.
Anne, use the original queue you had for actually printing to. The existence of the raw queue (it doesn't matter what it's called, and it doesn't need to be actually used) is what makes system-config-printer write CUPS config that accepts raw jobs server-wide.
Tim. */
On Tuesday 14 November 2006 12:59, Tim Waugh wrote:
On Tue, 2006-11-14 at 12:30 +0000, Anne Wilson wrote:
It's a bit basic - no duplex, no 2-up printing, but at least it prints.
Anne, use the original queue you had for actually printing to. The existence of the raw queue (it doesn't matter what it's called, and it doesn't need to be actually used) is what makes system-config-printer write CUPS config that accepts raw jobs server-wide.
Something wrong, Tim. Nothing came out, so I checked the cups interface on the server and saw that the printout had gone to the raw server:
Description: For use with XP Location: For use with XP Printer State: idle, accepting jobs. "Sending print file, 1205831 bytes..." Device URI: usb:/dev/usb/lp0
It tells me that I don't have permission to do anything with this printer - I had given the root password. Obviously I need to clear the queue of this file, or nothing else is going to print, even with the basic raw printer setting.
Anne
On Tue, 2006-11-14 at 13:24 +0000, Anne Wilson wrote:
It tells me that I don't have permission to do anything with this printer - I had given the root password. Obviously I need to clear the queue of this file, or nothing else is going to print, even with the basic raw printer setting.
Use the web interface to clear out print jobs. Don't use the raw queue for printing to; it just needs to exist and not be used.
Tim. */
On Tuesday 14 November 2006 13:30, Tim Waugh wrote:
On Tue, 2006-11-14 at 13:24 +0000, Anne Wilson wrote:
It tells me that I don't have permission to do anything with this printer
- I had given the root password. Obviously I need to clear the queue of
this file, or nothing else is going to print, even with the basic raw printer setting.
Use the web interface to clear out print jobs.
It won't let me. There are no jobs listed, so I tried to stop the printer. It said:
Forbidden You don't have permission to access the resource on this server.
I had logged into the web interface as root.
Don't use the raw queue for printing to; it just needs to exist and not be used.
Tim. */
I didn't, but it ended up in the raw queue. I don't know whether I'll get any more time to play with this tonight, but if I can only find a way to get that job out of the queue I'll experiment more tomorrow.
Anne
On Tuesday 14 November 2006 16:35, Anne Wilson wrote:
On Tuesday 14 November 2006 13:30, Tim Waugh wrote:
On Tue, 2006-11-14 at 13:24 +0000, Anne Wilson wrote:
It tells me that I don't have permission to do anything with this printer - I had given the root password. Obviously I need to clear the queue of this file, or nothing else is going to print, even with the basic raw printer setting.
Use the web interface to clear out print jobs.
It won't let me. There are no jobs listed, so I tried to stop the printer. It said:
Forbidden You don't have permission to access the resource on this server.
I had logged into the web interface as root.
Don't use the raw queue for printing to; it just needs to exist and not be used.
Tim. */
I didn't, but it ended up in the raw queue. I don't know whether I'll get any more time to play with this tonight, but if I can only find a way to get that job out of the queue I'll experiment more tomorrow.
Anne
Using system-config-printer, I discovered that the raw printer queue had not be set to shareable, so I enabled that, then tried another print from XP. Nothing came out, but at least the print queue no longer looked 'bunged up'. Examining the Completed Jobs list I found several entries like
Printer-1144 smbprn.00000044 Home - Mandriva Anne 230k cancelled at Tue Nov 14 22:10:06 2006
I did not cancel anything - it wouldn't let me. Looking at the timestamps for the cancellations, though, maybe it did cancel, or at least mark it to be cancelled later.
I then, as root, tried to restart the last job (tried it on another one, too) and got
Error: client-error-not-possible
I have only ever seen that in the past when I was not logged in as root.
Has *anyone* any idea what is happening? It doesn't make any sense to me at all. I'm beginning to wonder if an update has introduced a bug.
Anne
Tim Waugh wrote:
On Tue, 2006-11-14 at 12:30 +0000, Anne Wilson wrote:
It's a bit basic - no duplex, no 2-up printing, but at least it prints.
Anne, use the original queue you had for actually printing to. The existence of the raw queue (it doesn't matter what it's called, and it doesn't need to be actually used) is what makes system-config-printer write CUPS config that accepts raw jobs server-wide.
Tim. */
For the sake of reverse-engineering, what difference in the printers.conf or cupsd.conf file does it make if you include the "raw" versus leaving it out?
-Philip
On Tue, 2006-11-14 at 11:51 +0000, Anne Wilson wrote:
On Tuesday 14 November 2006 11:03, Tim Waugh wrote:
On Tue, 2006-11-14 at 10:32 +0000, Anne Wilson wrote:
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Oh - and the server is FC4. Does that make any difference?
No, no difference as far as system-config-printer and raw queues goes.
Tim, I can't see how to do it in s-c-p. The only queue types I am offered are
Locally-connected Networked CUPS (IPP) Networked UNIX (LPD) Networked Windows (SMB) Networked Novell (NCP) Networked JetDirect
As I have said before don't use s-c-p for anything on a FC4 machine. raw is the name of the queue not the protocol.
On Tuesday 14 November 2006 06:03, Tim Waugh wrote:
On Tue, 2006-11-14 at 10:32 +0000, Anne Wilson wrote:
On Tuesday 14 November 2006 10:25, Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Oh - and the server is FC4. Does that make any difference?
No, no difference as far as system-config-printer and raw queues goes.
Fedora Core 6, you'll be glad to hear, doesn't need you to do any of this.
But, HAL only sets up one printer Tim, and I'm used to at least 3, each set to a different, known to be working profile. Its much easier to just send the job to the right profile than it is to go into the properties and set it up for each job, that sucks.
rant mode on
But quess what, I couldn't do it like the hal method, I had to use the locally usb connected path, and gimp-print-ijs, whose quality is terrible on an epson. And each one seems to have its own idea of where the top of the page is, with a total vertical wobble of over an inch from one of those profiles to the next. I took my problems to the gimp-print list and was told I'd have to build gutenprint from a tarball to fix that.
This is not as big a reason as I had to do all 3 of those (cups/gimp/gutenprint) on FC2 before it would work, which resulted in what yum and synaptic thought was a broken system, but I don't want to have to go thru that again to get proper printing to work. When, after 4 core releases since the FC2 & cups debacle, printing is still screwed up by using the supplied rpms, I'm disappointed, because it surely seems the screwup is intentional. For instance, I have gutenprint and its extras also installed, they work much better than the gimp-print-ijs/foomatic crap with epson printers, but if I setup a printer with the gutenprint alone, then cups complains of a missing script. This is using the web interface, which has always worked flawlessly when all this is installed from tarballs.
Now, I'm running your system-config-printer utility, and its broken, clicking on the change button next to the URI does nothing, zip. Humm, I take it back, but why should it take nearly a minute to open that window, and why does it not give me the same HAL derived choice to use that HAL used?
I have historically used the IPP for everything as that seems to do the job of making the printer available to the rest of my network here, but copying what I used in FC2 (with cups-1.2.2) fails totally now.
Trying to select a gutenprint only driver, in the GB_en version gets me a message that I must install the gimp-print-cups package to use it. WTF? gutenprint IS its replacement and has been for what, 2 years? It does a noticeably better job for the color than gimp-print-4.2.7, so why are we being forced to use outdated drivers just to satisfy the fedora vision of how this is supposed to work? Its installing now to see if its any better.
Humm, economy draft mode in greyscale at 360x180 dpi. The image is 1 cm high on the page. This is using the cups+gutenprint-5.0-ijs ppd.
At this point I installed gimp-print-cups-4.2.7.
Now, setting up an lp1, my former default, same driver but at 360dpi in color, its finally located at the right place on the paper, and the color under removal is better. Not invisible, but noticeably better.
And finally, an lp2, for best quality photo use on heavy matt paper. Same driver, 1440x, so this will be about 15 minutes for a test page on regular top quality paper.. By golly, its now vertically centered on the paper. But color under removal still sucks, the wheel looks as if each wedge goes to full ink by the time its 25% of the way to the center, and the central 40% of the wheels diameter is just overlaid with black. Very poor color saturation inside that 25% outer area. This I can play with and hopefully improve.
And a fresh test page to the economy draft lp0, after installing the gimp-print-cups package, is also now properly centered on the paper too. I just changed the HAL derived (and default) setup to use this same ppd, and its now properly centered on the paper too, with a better looking color wheel, but now its at 720x360. At 720x720 it goes into microfeed, 20x slower so thats out.
But why should I have to install gimp-print-cups-4.2.7 just to use gutenprint-cups-5.0? It is also installed, and should Just Work(TM) so can we file a bugzilla because it doesn't?
I don't really care what method works, as long as it works and I can share them on my network, but a different place on the page for the output, with differences of an inch from one profile to another is not acceptable. Neither is poor gamma, and color under removal that goes to a flat grey long before its even as dark as an 18% kodak card. If it cannot be fixed, then I'll "break" my system again by installing the tarball(s) from the src(s). Only this time I will probably use checkinstall to do the make install so at least the rpm database knows its there.
rant mode off
I wrote the above paragraph before installing gimp-print-cups-4.2.7, which I shouldn't have to do, but now its acceptable so I'll shut up about it, till the next time...
On Tue, 2006-11-14 at 09:02 -0500, Gene Heskett wrote:
But, HAL only sets up one printer Tim, and I'm used to at least 3, each set to a different, known to be working profile. Its much easier to just send the job to the right profile than it is to go into the properties and set it up for each job, that sucks.
What's it got to do with HAL? Use the 'copy printer' button if you want to duplicate queues.
But quess what, I couldn't do it like the hal method, I had to use the locally usb connected path,
Why not?
and gimp-print-ijs, whose quality is terrible on an epson. And each one seems to have its own idea of where the top of the page is, with a total vertical wobble of over an inch from one of those profiles to the next. I took my problems to the gimp-print list and was told I'd have to build gutenprint from a tarball to fix that.
But Gene, *I* told you what the fix was: install gimp-print-cups. I told you on that list! Did you try it?
For instance, I have gutenprint and its extras also installed, they work much better than the gimp-print-ijs/foomatic crap with epson printers, but if I setup a printer with the gutenprint alone, then cups complains of a missing script.
This is because there are some scripts that both gimp-print-cups and gutenprint-cups want to supply. Since we have not yet made the full transition to gutenprint, gimp-print-cups provides those at the moment. The packaging bug that gutenprint-cups not requiring gimp-print-cups is (I'm told) going to be fixed in the next few days.
Now, I'm running your system-config-printer utility, and its broken, clicking on the change button next to the URI does nothing, zip. Humm, I take it back, but why should it take nearly a minute to open that window, and why does it not give me the same HAL derived choice to use that HAL used?
I don't know. Why don't you file a bug report about it and help me fix that? I have been working very hard to fix system-config-printer problems for the last few months, and I'm taking bugzilla reports in priority order. Issues that aren't even in bugzilla are just not going to get fixed, so file bugs!
I have historically used the IPP for everything as that seems to do the job of making the printer available to the rest of my network here, but copying what I used in FC2 (with cups-1.2.2) fails totally now.
I don't know what you mean here.
Trying to select a gutenprint only driver, in the GB_en version gets me a message that I must install the gimp-print-cups package to use it. WTF? gutenprint IS its replacement and has been for what, 2 years?
The gimp-print-cups package is required for commandtoepson and commandtocanon. We can't have conflicting packages in Fedora, so one of gimp-print or gutenprint had to take these filters. gimp-print is what we're still shipping -- and I really wish we'd had time to incorporate gutenprint -- and so that's where those filters are.
But why should I have to install gimp-print-cups-4.2.7 just to use gutenprint-cups-5.0? It is also installed, and should Just Work(TM) so can we file a bugzilla because it doesn't?
There is already a bugzilla filed, and the fixed package will be pushed out in the next few days I'm told.
Tim. */
On Tuesday 14 November 2006 09:40, Tim Waugh wrote:
On Tue, 2006-11-14 at 09:02 -0500, Gene Heskett wrote:
But, HAL only sets up one printer Tim, and I'm used to at least 3, each set to a different, known to be working profile. Its much easier to just send the job to the right profile than it is to go into the properties and set it up for each job, that sucks.
What's it got to do with HAL? Use the 'copy printer' button if you want to duplicate queues.
But quess what, I couldn't do it like the hal method, I had to use the locally usb connected path,
Why not?
Twasn't a menu choice and it was too long to copy/paste by hand.
and gimp-print-ijs, whose quality is terrible on an epson. And each one seems to have its own idea of where the top of the page is, with a total vertical wobble of over an inch from one of those profiles to the next. I took my problems to the gimp-print list and was told I'd have to build gutenprint from a tarball to fix that.
But Gene, *I* told you what the fix was: install gimp-print-cups. I told you on that list! Did you try it?
Have now, it works but there are diffs in the color.
For instance, I have gutenprint and its extras also installed, they work much better than the gimp-print-ijs/foomatic crap with epson printers, but if I setup a printer with the gutenprint alone, then cups complains of a missing script.
This is because there are some scripts that both gimp-print-cups and gutenprint-cups want to supply. Since we have not yet made the full transition to gutenprint, gimp-print-cups provides those at the moment. The packaging bug that gutenprint-cups not requiring gimp-print-cups is (I'm told) going to be fixed in the next few days.
Now, I'm running your system-config-printer utility, and its broken, clicking on the change button next to the URI does nothing, zip. Humm, I take it back, but why should it take nearly a minute to open that window, and why does it not give me the same HAL derived choice to use that HAL used?
I don't know. Why don't you file a bug report about it and help me fix that? I have been working very hard to fix system-config-printer problems for the last few months, and I'm taking bugzilla reports in priority order. Issues that aren't even in bugzilla are just not going to get fixed, so file bugs!
Well, I think it was burning rubber in the background reading and sorting all the ppd files. But it would be nice if the mouse changed to the busy symbol to at least let you know the button had been clicked on. :)
I have historically used the IPP for everything as that seems to do the job of making the printer available to the rest of my network here, but copying what I used in FC2 (with cups-1.2.2) fails totally now.
I don't know what you mean here.
The missing stuff in gutenprint-cups.
Trying to select a gutenprint only driver, in the GB_en version gets me a message that I must install the gimp-print-cups package to use it. WTF? gutenprint IS its replacement and has been for what, 2 years?
The gimp-print-cups package is required for commandtoepson and commandtocanon. We can't have conflicting packages in Fedora, so one of gimp-print or gutenprint had to take these filters. gimp-print is what we're still shipping -- and I really wish we'd had time to incorporate gutenprint -- and so that's where those filters are.
But why should I have to install gimp-print-cups-4.2.7 just to use gutenprint-cups-5.0? It is also installed, and should Just Work(TM) so can we file a bugzilla because it doesn't?
There is already a bugzilla filed, and the fixed package will be pushed out in the next few days I'm told.
Oh Goody. Thanks Tim.
Tim. */
Tim Waugh wrote:
As I said originally, make a new raw queue using system-config-printer. It has to be a new queue, it has to be raw, and it has to be made using system-config-printer.
Tim. */
We're burning install DVD's with %post installation sections that create and provision NFS file shares, printers, LDAP servers, etc.
Having the user hand-create the printer queues isn't an option.
Isn't "lpadmin" supposed to be able to do everything that the server on port :631 does?
-Philip
On Tue, 2006-11-14 at 12:37 -0700, Philip Prindeville wrote:
Having the user hand-create the printer queues isn't an option.
For kickstart %post scripts, use printconf-tui to create the raw queue. The '--Xexport' and '--Ximport' options are what you need.
Isn't "lpadmin" supposed to be able to do everything that the server on port :631 does?
What we are battling in this thread is a quirk of the way system-config-printer worked before it was re-written to avoid any of this being necessary. It is no longer necessary in Fedora Core 6. The big bug of system-config-printer having its own special configuration files has been fixed.
Tim. */
Tim Waugh wrote:
On Tue, 2006-11-14 at 12:37 -0700, Philip Prindeville wrote:
Having the user hand-create the printer queues isn't an option.
For kickstart %post scripts, use printconf-tui to create the raw queue. The '--Xexport' and '--Ximport' options are what you need.
Isn't "lpadmin" supposed to be able to do everything that the server on port :631 does?
What we are battling in this thread is a quirk of the way system-config-printer worked before it was re-written to avoid any of this being necessary. It is no longer necessary in Fedora Core 6. The big bug of system-config-printer having its own special configuration files has been fixed.
Tim. */
Not to rehash the issue, but I'm still not clear: why would the behavior of system-config-printer (which is optional) interfere with the basic functionality of cups-lpd?
And how is it the regression testing of "cups" for the CLI commands ("lp", "lpadmin,", etc) didn't uncover that all of this had stopped working?
Seems odd that in Unix, where scripting and the CLI rule the roost, that the basic commands stopped working and only the CLI functions correctly.
-Philip
P.S. I tried creating the Generic Printer/Raw queue with the GUI tool, but that didn't solve the problem...
On Tue, 2006-12-12 at 19:56 -0700, Philip Prindeville wrote:
Not to rehash the issue, but I'm still not clear: why would the behavior of system-config-printer (which is optional) interfere with the basic functionality of cups-lpd?
It's CUPS as a whole, not cups-lpd (see previous messages). system-config-printer before FC6 is only optional in that if you have it installed, it (and no other tool) must be used to manage the queues. This is a constraint the design (circa RHL8, pre-dating CUPS's inclusion), and there was never enough time for a re-design or a re-write.
P.S. I tried creating the Generic Printer/Raw queue with the GUI tool, but that didn't solve the problem...
Try editing /etc/cups/mime.convs and uncommenting the line at the end. I seem to recall that the printconf-backend for CUPS only adjusts one of mime.convs/mime.types.
Tim. */
-
Aaron Konstam -
Anne Wilson -
Gene Heskett -
Jack Byers -
Markku Kolkka -
Philip Prindeville -
Tim Waugh