Post by Ciprian Marius VizitiuOh Kurt, thanks a *LOT* for weighting in, I've been struggling with this
problem for... quite some time now. :-|
Sorry, today my answers will be rather short (and maybe incomplete)...
not so much time right now...
Post by Ciprian Marius VizitiuPost by Kurt PfeifleA "raw" printqueue in CUPS is one that has *no* PPD assigned
to it. A queue without a driver, if you like.
Basically you say: "send all jobs to printer unchanged +
unfiltered, when- ever you receive them, from whichever
client". (This assumes, the job is in a file format that the
target printer will be able to understand and process).
"Raw printing" from a Windows client does also mean "File is
print-ready, do not process any further".
Your explanation sounds *exactly* as I thought it should be, yet facts
don't...
Ok the story from the very beginning: I have a small network consisting of
XP WS using a Samba PDC and CUPS driving a bunch of printers; no
"WinPrinters" here all "100% Linux compatible" linuxprinting.org "certified
ware"; Samba 3.0.10 and CUPS 1.1.22.
Both version are rather old... (3.0.10 == December 2004; 1.1.22 == Oct 2004)
I personally haven't used them since quite some time.
Latest CUPS from the 1.1.x series is 1.1.23 (released Jan 2005). And of
course, we since had 1.2.0 to 1.2.12 as well as 1.3.0 ...
Latest Samba is 3.0.25c (released yesterday).
Have a look at http://www.cups.org/relnotes.php and search for keywords that
may be related to your problems (like "PDF" to see if there were fixes in
newer releases).
And if you search for "print" or "cups" in the Samba release notes (see
http://us1.samba.org/samba/history/samba-3.0.25.html as well as
http://us1.samba.org/samba/history/samba-3.0.25a.html as well as
http://us1.samba.org/samba/history/samba-3.0.25b.html as well as
http://us1.samba.org/samba/history/samba-3.0.25c.html) for all printing
related changes and fixes since 3.0.10).
Post by Ciprian Marius VizitiuI could send the smb.conf and
cupsd.conf if you want to but it's kinda pointless because all setup was
done as per your very good printing how-to (after drawing you the diagrams
from the ASCII art for that how-to, time to make some good use of it, don't
you think?! ;-) ). Drivers for the printer(s) were installed on the Samba
server via the "add printer wizard" so first time a Windows box connects to
the printer share the drivers get installed "automagically" on the local
machine; since "root" has set up his printing preferences, miracle of modern
technology, all drivers installed have the default values set for duplex,
toner density, A4 and like. I chose the "smart Windows drivers - dumb CUPS"
version because the print drivers running on Windows gave me more options
(and is more "user friendliness") as compared to the CUPS's web page.
Consequently CUPS queues were set-up as RAW and I'm telling you, this setup
worked pretty well for more than a year up until (and including) CUPS
1.1.17. So I guess the config files should be OK?! :-o Oh and yes, I *DO*
have "cups options = raw" in smb.conf
OK, there was one "small problem" though but it's not CUPS related, it's
Samba. During the initial setup of the rig, for the Lexmarks T430 I had the
option of installing two type of drivers: PCL or PS. Of course I jumped into
PCL from the very beginning, but! If one installs a PCL printer driver in
the above setup (that is Windows XP Pro, all updates in place and a Samba
printer share, Samba acting as PDC) everything works well until you want to
change some of the printer settings... Any of them; actually it's not the
change it's pressing the "Apply" button on the driver's window. :-] The very
next moment you "Apply" the settings XP freezes for like 2 or 3 minutes...
There were a few notorious PCL drivers (from HP as well as from Lexmark
and others) which caused this type of problems. Especially if the number
of "Dependent Files" for the driver was exceedingly large (I've seen insane
numbers like 70 or 80 .dlls or a single driver....).
This is *much* better now with newer Samba releases (but I'm not sure if
really *all* problems are fixed).
Post by Ciprian Marius VizitiuWhen it comes back to life no settings have been applied. BTW, if someone
knows the magic incantation(s) for this problem please step up!
The only advice I could give (from the distance) is this: testdrive it with
the newest Samba release (and use CUPS 1.1.23 or the latest 1.2.x) and see
if this problem has gone away....
Post by Ciprian Marius VizitiuAfter one
frustrating week of mangling permissions and smb.conf I called it a quit and
hesitantly changed to PS drivers so I can proceed with my installation. Well
it worked, drivers installed and allowed me to change settings, I could
set-up the whole thing the way I wanted, Windows PS drivers now outputting
some sort of PS through Samba and then to CUPS RAW and from there to
printer...
This can only work with CUPS raw printing, if the print device is PS-
capable...
(Some devices can take PCL as well as PostScript, but need to be set up
for auto-switching their PDL language).
Post by Ciprian Marius VizitiuAll went well until the next update after 1.1.17 (which was like Dec. 2005
if I remember well). After that date certain jobs submitted as before (I
haven't changed a thing!) will pass through Samba, make it to CUPS but then
vanish in a black hole; oh and CUPS will start using some 60% of the
server's CPU time,
It would be interesting to see if it is cupsd itself, or a filter or a
backend process which consumes the CPU...
Post by Ciprian Marius Vizitiuother jobs will start piling up... Sometimes the printer
ERROR: undefined
This may be caused by Ghostscript filter, when a PostScript file has a
PJL header prepended....
But it also means that the printqueue is *not* fed with "raw" job data
(there may be a non-PS printer in the backend?)...
Post by Ciprian Marius Vizitiu... Or something in the line of. I reverted to 1.1.17 for a while; Then
subsequent CUPS releases in the 1.1 series fixed the CPU usage but didn't
fix my problem. So here I am with a print server working in 3 cylinders,
every now and then having to restart CUPS...
About the problematic documents: the problem shows up in some PDFs
I assume you're printing the PDFs from some version of Adobe Acrobat
(Reader)? Which version?
The Acrobat printing is somehow different from printing of Office files
(it provides its own PostScript driver, and its print dialog allows for
all kinds of additional tweaks).
Have you played with settings like "print as image" for example? Or
with settings that
Post by Ciprian Marius Vizitiunever in
"text" prints or Microsoft Office generated dox. Chances are "graphics
intensive" HTML pages *when printed from Firefox* will also produce the
problem. Adding insult to injury: take the VERY same HTML page and print it
from Exploiter, works like a charm... makes no sense.
Which version of Firefox?
FF sometimes indeed does have problems creating a clean, valid PS file that
is processed without a problem by older versions of Ghostscript.
Firefox uses its internal PS-producing engine for print job creation, which
is different from what IE uses....
However, I've seen the same thing vice-versa: IE suffering print problems
with pages that printed alright from FF.
Post by Ciprian Marius VizitiuPost by Kurt Pfeifle(Did you
follow the Samba Howto Collection procedures to install the
driver on the Windows Clients?
I did! And, as I explained above, I had no choice but to use the PS driver.
Maybe I should add some more details, someone might make good use of this.
It is my deep suspicion that using a PCL driver would fix the problem for
good! But then how to coerce Samba into cooperation? :-|
At least for those Lexmark printers (CUPS and Samba aside!) the PCL drivers
are clearly "smarter" than the PS ones. Simple example(s): one PDF (which
also produces the CUPS problem...) printed directly from XP to the
aforementioned Lexmark printer, via USB, has a slightly different appearance
"via PCL" as compared to "via PS"; fonts are slightly different...
I assume it is at least PCL 5?
PCL driver doesn't necessarily use the same fonts...
Post by Ciprian Marius VizitiuOh, a PDF
printed via PS can "override" the page size but it won't do it via PCL...
Yeah, that's a feature of the individual drivers...
Post by Ciprian Marius VizitiuI
know it sounds silly but that's how it is. What do you mean "it's a feature,
it's not a bug!"? :-> Even more, this particular PDF comes out without the
letters "i" via PS but comes out correctly via PCL! I've opened a case with
Adobe and they said the PDF is "broken", something about the embedded fonts
and that Adobe can not be held responsible for...
Did you yourself check the PDF with some kind of "preflight" software?
Post by Ciprian Marius VizitiuRight. If it's broken why
does it work via PCL?
Probably, because the PCL driver generates pixelized images of the full pages
(or of the font's characters) and embeds this into the file...
Post by Ciprian Marius VizitiuAnd why did it print very well via PS on CUPS
v1.1.17?! :-|
You can still try to change the font settings in the Windows driver dialog
(there are options for TrueType fonts like "send as outline", "send as bit-
map" or "send as softfont")....
Post by Ciprian Marius VizitiuPost by Kurt PfeifleCUPS is always doing "auto-typing" of the job files
(determine the MIME type of the data) by default (also for
Samba submitted jobs), unless it sees the command line option "-o raw".
Critical question: Do I have to manually specify the option "-o raw" or does
Samba insert it once I have the "cups options = raw" in smb.conf?!
Post by Kurt PfeifleIn recent Samba versions you can set "cups options = raw" in
smb.conf, which tells Samba to explicitely request raw
printing from CUPS.
Oh, kinda answers my question above, doesn't it?! :-(
Yes, in a way, but not completely.... :-)
Post by Ciprian Marius VizitiuPost by Kurt PfeifleIf CUPS auto-types a job as "application/octet-stream", it
will not auto matically "pass the bucket", unless...
(a) either the "-o raw" commandline parameter is seen (for
example be-
cause of the "cups options = raw" in smb.conf), or
(b) application/octet-stream is generally enabled in the
mime.types and
mime.convs files of CUPS
I should *also* have hinted at the difference of the two things:
(a) will cause CUPS raw printing for *all* Samba-supplied job
files
(b) will cause CUPS raw printing only if auto-typing determined
'application/octet-stream' (and will apply the standard fil-
tering chain construction for all other mime types).
Post by Ciprian Marius Vizitiu... 've been here before. To be on the safe side I have both the raw Samba
conf option and application/octet-stream in mime.*! :-z Neither helps...
Hmm... maybe a bug in Samba, where it does not really pass the "-o raw"
parameter to CUPS?
(I *seem* to remember speculations about that some long time ago, for
some $version of Samba, but can't remember details...)
Post by Ciprian Marius VizitiuQuestion remains: Why would CUPS be affected by something it is NOT supposed
to look into?
One last idea you could try:
(a) remove "printing = cups" and "printcap = cups" from smb.conf.
This will cause Samba to now require and use the "* command = ..."
set of options.
(b) insert "printing = bsd", and also define all the commands to be
used by Samba to pass the job to CUPS. For example:
print command = "lp -d %p -t %J -o raw %f; \
rm %s; \
echo $(date): Printed and deleted jobfile %s submitted by %U from %m >> /tmp/smbprint.log"
See 'man smb.conf' for details...
The trick here is to explicitely pass on "-o raw" in the print command
to see if this overrides or works around a potential bug in your Samba
version....
--
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH ..................... Hedelfinger Strasse 58
A RICOH Company ........................... D-70327 Stuttgart/Germany