NT print requests getting filtered wrong
2007-12-25 9:46:00
let me just say that "My OS can beat up your OS" (substitute your favorite
and least favorite OS's at your discretion).
Ok, now that we've progressed beyond that silliness... Here's a quick
restatement of the problem. I have an HP Postscript printer that is
currently hooked up to a dying NEXT print server. We also have an NT
server that has a printer configured in PrintMangler to spool to a
SUNOS 4.1.3 machine, which sends it on to the NEXT (I don't know why --
I haven't been working here long and am still cleaning up strangeness).
The NT and UNIX print requests have been printing fine, until the NEXT
crashes, drops off the LAN, or just decides to drop the job :-(
I was trying to move the printer to a nice, fast Solaris 2.4 machine
and have *all* of our machines spool to it (a more reliable machine than
the NEXT, and jobs take fewer hops across the LAN). All of the UNIX
platforms were able to print to this new printserver fine. Print jobs
from the NT machine, however, would print the postscript source code --
the Solaris printserver was convinced the jobs were type "simple" and
needed to be filtered with "postprint". Looking at the contents of the
spool on the Solaris printserver, I could see no reason for the
printserver to think it was type "simple" (ie. no leading junk in the
postscript file).
I had hoped that there was at least one other sun-manager who had
encountered this problem, and wondered if it was a known oddity of the
Solaris 2.4 printer daemons, a known oddity of the NT PrintMangler, and/or
any workarounds. I also posted to two NT admin newsgroups and got *no*
response (I s'pose it's obvious to them that it's a UNIX problem, eh?)
I got one chastisement for posting what was obviously (not to me)
an NT problem to sun-managers (even though it *was* a SUN printserver),
one offer of source for a BSD-style print filter that sounded more
robust (thanks) and several "me-too"s. I also got two messages referring
to the leading Ctrl-D problem Windoze 3.1 has (it sticks extraneous junk
in front of the %! making print servers and often printers think that the
file is ASCII, not Postscript). This, however, wasn't my problem.
The crux of the problem seems to be in the header that gets sent along
with the file to be printed. When the NT spools something using
PrintManager (or any software that spools with PrintMangler -- ie. almost
anything), it sends a "type character" of "l" in the header. These jobs
get filtered, and the postscript source gets printed.
The UNIX jobs all have a "type character" of "f" in the header, and
these jobs get printed fine. Furthermore, on NT, there is an LPR
command that I can use to bypass PrintMangler. It uses a type
character of "f" by default, and Postscript files printed by this
means work fine. So far, I haven't seen any way of changing PrintMangler
so that it sends the right stuff in the print header, and I'm not sure
that hacking around with lpadmin to get the Solaris printserver to never
filter anything, but accept anything and print it as is, is an appropriate
solution.
So, the summary of the summary (grin) is that it is a PrintMangler
(read NT) problem, not a UNIX problem, and I have not found a solution.
Perhaps now that I have something more specific to point a finger at,
the other NT admins reading the NT newsgroups will be more helpful when
I repost.
Thanks again, to all who responded, and to everyone on sun-managers
(at least I got *some* response from sun-managers - grin).
Brent Bice
Comments
Got something to say?
You must be logged in to post a comment.
