Date: Sat, 8 Jul 2000 14:01:05 -0700 (PDT) From: papowell@astart.com To: chuckr@picnic.mat.net, papowell@astart.com Cc: andrews@technologist.com, arch@FreeBSD.ORG, drosih@rpi.edu, imp@village.org, nik@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Subject: Re: Bringing LPRng into FreeBSD? - License Issues Message-ID: <200007082101.OAA26787@h4.private>
next in thread | raw e-mail | index | archive | help
I have been reviewing some of the postings that folks have sent on
this topic, and I would like to provide some clarification about
printing.
I think that there is a bit of confusion about the overall issue
of printing. This is probably due to the fact that most people
close their eyes to printing as soon as it is working for them,
and hope never to get involved with configuring it again. A MOST
perceptive and reasonable attitude, given the horrible state of
printing.
Lets start at the back end.
What Gets Sent To The Printer
Basically, a stream of bytes. The FORMAT of this stream of
bytes is the critical issue. Most printers usually support a
limited number of formats that they recognize:
PCL - this is really text + control sequences
PostScript - this is PostScript
Now this is the 'basic' format. In addition, most printers
require additional structure on this format, or additional
'support' for various things:
PJL - Printer Job Language
HP printers use this for 'metacontrol' of printers
PostScript Document Structure Conventions
How you will organize the PostScript
PostScript PPD + Embedded Control Commands
PostScript Printer Description files tell WHAT
capabilities a printer has
You use this to put commands into a PostScript file
that will cause the printer to select the correct
input bin, output bin, paper type, etc.
How Does It Get There
You can send it over a communication channel -
Serial Channel
Parallel Channel
Network Channel
Each of these channels MAY have a protocol used to transmit documents
of a specific format. For example, if you want to send 'binary PostScript'
over a 7 bit serial channel, then you need to use the 'TBCP' encoding
for your PostScript job.
Network Channels are REALLY fun, because you have not only the basic
network level protocol, (TCP/IP, IPX, AppleTalk, etc.), but also
application protocols such as the 'Appsocket', 'Socket', RFC1179, and others.
This is why just sending a file to the printer via 'cat' or 'netcat' may
have some unexpected side effects. Such as the file not getting printed :-).
Print Spooler or Manager
This is effectively the interface between a user program that is generating
a job to print and the actual device. In some cases, this is just
'open /dev/lp0 and write to it' by the application. But usually it is
a system service.
For example, the 'lpd' server and the 'lpr' client programs are the commonly
used BSD UNIX print spooler, 'lpsched' and 'lp' on SystemV, and so forth.
These system work by having the user or application use the client program
send a copy of print job to the server program via a network connection
(or copy it to a special spool queue directory). The server then sends the
job to the appropriate printer using the appropriate protocol on the appropriate
interface or network address.
Format Conversion
Many times print jobs are in a format not supported by a printer. This
means that Format conversion must be done on the print job. You might
also want the 'Make the printer do this' which are part of the print job
or meta information to be preserved by the format conversion.
Application Print Job Generation
This is the actual generation of the print job, i.e. - a string of
bytes + meta information about the job.
In many of the postings, I noticed that people were referring to
apsfilter, a2ps, etc., GhostScript, and other programs. These are
used in the printing process as FORMAT converters.
Where is the format conversion done?
You can do it in the application program. This is common. For
example, a screen dump program will convert the raster image to
PostScript, PBM, or some other format. However, many application
programs produce only one output format, perhaps suitable for
only one type of printer. If the output is PostScript, then
usually it is pretty simple and will print on almost all PostScript
printers. But not always.
You can do it by having the application program send
its output to the format converter, which then passes it to
the print spooler. This is where a2ps, magicfilter,
and other format conversion programs are used. Usually
these work by determining the input file type, the desired
output file format, and then running a set of conversion
programs on the file until the desired file format is
produced.
You can have the print spooler do the format conversion.
This usually is done by having the print spooler call the
a2ps, magicfilter, or formatconversion. The benefit of this
is that the print spooler usually has a better idea of the
desired output format and can provide more information to the
conversion process. This usually (not always!) gives better
conversion results.
Question: Do I need format conversion?
Answer: If your files are in the same basic format as your
printer requires, then you do not require format conversion.
Question: But my printer does not understand PostScript and
I want to print PostScript files!
Answer: Then you will require a PostScript to printer compatible
input converter. GhostScript has support for a very wide variety
of output formats.
Question: Why is this so complicated?
Answer: because there are a large number of choices at each point,
and a large number of different applications generating output.
And a very long set of legacy applications and formats.
Question: What is a 'printer driver' and why doesn't UNIX have them?
Answer: The 'print driver' that you are talking about is really
a set of configuration information AND a set of conversion libraries
that are used by application programs to generate output that is
compatible with a device. There is a well defined set of API's
for these conversion routines, and a well defined set of API's
that allow the conversion routines to determine what capabilities
printers have.
Microsoft has changed the methods and APIs for doing printing at least
4 times... This has the benefit that they do not have to support
legacy APIs, and can update their printing stuff fairly easy by
simply replacing everything each release.
Question: Well, why doesn't somebody do this for UNIX?
Answer: This has been done several times, but the problem is one
of 'legacy' software and 'proprietary' interfaces. Several attempts
have been made to do this, but this would require a lot of programs
to be retrofitted with this capability. In addition, several of the
proposed standards required the purchase or use of special libraries,
etc., that did not sit well with various users.
Patrick Powell Astart Technologies,
papowell@astart.com 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 858-874-6543 FAX 858-279-8424
LPRng - Print Spooler (http://www.astart.com)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007082101.OAA26787>