On Thu, Apr 03, 2003 at 09:17:23AM -0500, tallison@tacocat.net wrote:
| > On Thu, 03 Apr 2003 06:06:05 -0500
| > Tom Allison <tallison@tacocat.net> wrote:
| >
| >> > | I started to try this approach and died here:
| >> > |
| >> > | Setting up cupsys (1.1.15-4) ...
| >> > | Starting CUPSys: cupsd.
| >
| >> I have what is supposed to be a network printer with support for
| >> JetDirect, Cups and LPD. Unfortunately, it isn't exactly a cups
| >> server. So I guess in order to get my network printer working, I need
| >> yet another server....
You only need another server *IF* the clients send data which the
printer can't understand by itself.
| >> I guess the whole point was to set up a printer that didn't require
| >> another server. After all, it's got it's own hard drive and a 233MHz
| >> CPU.
My understanding is that the hard drive exists for large queues, and
the CPU is for running the PostScript/PCL interpreter. (this IS an HP
LaserJet, right? Or is it that Kyocera you mentioned another time but
with an expensive HP JetDirect card attached to it?)
| I guess I'm missing something then....
Yeah, just the issue of data format and conversion.
| Under Windblows, all they do is point and print the stupid jobs.
True. However each Winblows machine IS a server. (the beauty and
stupidity of fat clients) Each (windows) client must have the driver
installed so that Windows can translate from API calls into the data
stream the printer understands. Once the data stream is something the
printer understands it's a walk in the park.
| Under Linux, I can't seem to be able to do the same.
You can, if you mimic the "fat-client-no-server" philosophy of Windows
*OR* if you use a "thin-client-fat-server" architecture.
| Pointing to a 'raw' print mode doesn't seem to cut it.
That means the client sent some datastream which the printer doesn't
understand.
| Pointing to a port in (515, 610, 9100) also doesn't seem to cut it.
That means something was set up really wrong. Specifying a TCP port
is necessary, but not sufficient, configuration. It's only one layer
in the architecture.
| I think that the best I've achieved so far is with PDQ under 'raw' mode
| using the bsd-lpp interface. With this I think I get stair-casing.
Not bad for a start, with ASCII-only input. The stair-casing is
caused by Line Feed and Carriage Return semantics. Have you ever used
or seen a mechanical typewriter? Do you know how they have a lever
which feeds the line up by one, and also the "carriage" must be
returned to the beginning of the line? Well, the UNIX philosophy is
one of interfaces and adapters. Text files are "encoded" with only \n
(LineFeed) as the end-of-line indicator. The printer, and a number of
terminals, separate the LF and CR functionality. So, when you stuff a
UNIX file _directly_ to the device, the carriage is never returned
although lines are fed. Hence the stair-casing. The solution is to
filter the abstract data stored in the file and convert to what the
device needs. For this the filter is a matter of replacing \n with
\r\n. Simple, but needs to be configured per-device because each
device can be different in this respect.
| But I didn't expect this under a Postscript Printer using Postscript
| Drivers.
I don't think postscript came into play in the above, but I've never
used PDQ so I can't say for certain.
| I'm vague as heck on all of this because my printer is actually located
| some 1,500 miles away and I'm trying to do all of this through ssh. when
| I print something, I wait for an email from the (patient) end user to tell
| me if he found anything and what it looked like.
That makes it a bit difficult to fully determine what the printer
understands and the quirks of it. (apart from RTMing, and assuming
the documentation matches the implementation)
| What kills me is right now I take a PostScript file with a first line like
| "%! Postscript 2" (or whatever it's supposed to look like) and do 'pdq
| foo.ps' and the output from that comes in with that exact line three lines
| down and the first line being "%!".
PS files must start with "%!". "%" is the comment marker. So any
lines beginning with % are irrelevant, *IF* the parser on the other
end is robust. However, some structure has been introduced into
comments which simple parsers can use (*IF* the document is
well-formed) to located page separations and the like.
| Non-postscript files don't end up like this. But I'm unclear if they
| print at all. I do not believe that they do.
That means PDQ didn't do an adequate job of data conversion.
| so, I was thinking of trying CUPS but that initially didn't get me any
| further along. It was also a little unnerving that I have to run a cups
| server to talk to a network printer that (in theory) supports cups to
| begin with.
Try some experiments with the cups client software. For example, try
this :
lp -d port1@<printer.fqdn> /etc/modules
lp -d port1@<printer.fqdn> /usr/share/cups/data/testprint.ps
The first should print the plain text file, but probably will have the
stair-case effect noted earlier. The second should print the cups
test page on the printer.
Since the cups client software ('lp' & friends) speak IPP and the
printer speaks IPP it should just work without "another server" *IF*
the data sent is understandable by the printer.
| The problem here is that this really intelligent printer doesn't seem
| capable of acting as it's own server under both Windows and Linux. Oh
| well, that's another problem. I'm still trying to print foo.ps!
Data format issues again. See below for an outline on the
architecture here.
| To answer your question, I really don't know for sure if it has a hard
| drive, but it does seem to support telnet, ftp, http, cups, lpd, and
| jetdirect. Which is more than some computers can do.
That doesn't mean it actually has a hard drive. The JetDirect
interfaces are pretty neat, and the whole point of them is that you
don't need a dedicated PC to run it. (for example if the printer only
had a parallel port interface, and since most PCs have only 1 parallel
port, that means a one-to-one PC to printer connection until you run
"servers" on the PC to share the printer)
Here's the way network printing is organized, with a CUPS focus :
First you have the client software, the /usr/bin/lp. This software
receives data and options from the user and passes it to a server.
The default is to pass the data to the default printer (configured
server-side) on localhost. However, any other destination can be
specified. The CUPS lp (and 'lpr' if you prefer the BSD interface)
implementation uses the IPP protocol to pass information to the
server. If a printer name like "foo@bar" is used, then the client
contacts machine "bar" (instead of localhost) to submit the data to
printer "foo". The server is any software which implements the IPP
protocol. Typically it will be the cups 'cupsd' daemon, but it should
work just as well with the JetDirect card.
The server receives the job and options from the client. First I'll
explain this in terms of a cups server. cupsd looks at the data to
try and identify what it is (PS, PDF, Text, JPG, PNG, etc. etc.).
Then it looks at the PPD file associated with the printer queue to
determine what data format(s) the printer supports. The daemon
assembles a chain of filters which will massage the data from what the
client gave it into what the printer can deal with. (this is all
controlled by files in /etc/cups) When the data has been converted,
cupsd starts a "backend" process which will send the cooked data to
the printer device. cups supports many different types of "devices"
including parallel port, usb, smb, ipp, lpd, and jetdirect. (note
that the first two are real devices on the machine while the last four
are remote "devices" on the network)
In your case you are using one of 'lpd', 'ipp', or 'socket'
(jetdirect) as the device. So cupsd connects to the printer and feeds
it the (cooked) data. The printer takes it, processes it, and prints
it. The processing is (usually) limited to figuring out what
switches, motors, lasers and whatnot to activate when and how. It
isn't the same sort of processing that the cups server did when it
converted from (for example) PNG to PS.
Since the printer supports IPP, you can bypass the whole "cups server"
part in the middle, if you want to. Here's the tradeoff : the cliemt
MUST ensure that the printer understands the data it is trying to
enqueue. The client can't actually do that, apart from the admin
ensuring that all software (and users) which will submit data will
only submit data which the printer understands. It also means the
client must to all adjustments (eg scaling of images, enabling duplex
options, n-up layout, or inserting Carriage Returns in plain text)
before submitting the data to the queue.
Going back to the Windows comparision -- all Windows "clients" are
really fat because they embed the server in them. Hence the,
apparent, simplicitly in getting it to work. (however, it utterly
lacks scalability and management in a network of any size)
I recommend setting up a cups server on one machine and the client
software on all the machines. By doing this you get the advantage of
never worrying about stair-casing again, and you can directly submit
many different types of data to the printer and have the server adjust
it for you. For example, to print in duplex or 2-up mode (or both)
use commands like this :
# for duplex
lp -o sides=two-sided-long-edge
# for 2-up
lp -o number-up=2
# 2-up and duplex
lp -o sides=two-sided-long-edge -o number-up=2
You can also set up separate queues with these as default options.
You can print an image (say a dilbert comic) like this :
lp -o scaling=90 dilbert.gif
When you set up the cups server, you tell the server 1) where the
printer is (ipp://<...>) and 2) what the printer is (by choosing a
model in the web interface or specifying a PPD file to 'lpadmin').
Once you've done that you're (mostly) done! From the server you
should be able to print the test page (and anything else you have
handy) with no trouble. The PPD file takes care of telling cupsd what
the printer does and doesn't handle so it can do all the conversions
automatically.
On the clients, simply set the default printer in
/etc/cups/client.conf and they'll work just the same. (use
"printer@server" as the name, for example I have
DefaultClass@dman.ddts.net as the default)
Does this make sense now? Do you now understand why certain things
worked and others didn't in your experiments? Did I create more
confusion? Let us know how this turns out for you!
-D
--
He who walks with the wise grows wise,
but a companion of fools suffers harm.
Proverbs 13:20
http://dman.ddts.net/~dman/
Attachment:
pgp3RMiaAPFEY.pgp
Description: PGP signature