Slashdot Mirror

When we understand the way books are printed we would only understand its very different than what we would assume.Burning CD's and printing Books is quite different, CD printing is in a digital format, while plain paper printing, binding is a lot more time consuming and costly affair. Custom Internet books printed through digitial copier machines would cost a hell lot.

[...] not to mention the fact that the last page is still technically on the print drum till it is used again.

And, in some cases, the printers have debug modes where its entire memory (including the data spool) can be read out via SNMP. I believe this is a feature of the HP JetDirect print servers.

I don't know that there is a general way in which network printers can be secured. There's probably an encryption option in IPP, but I think you'd be hard pressed to find printers, print servers, and clients which support it.

What would be really neat would be if they could implement a rendering model based either on XML + CSS, or DVI, both of which are open standards. An XML based rendering standard would have more hope of catching on, though a DVI based one would almost certainly yield (substantially) better output.

Seems to me it'd be pretty straightfoward to implement the same thing in UNIX. Just set up an X server to emit PostScript code or HPGL or whatever and that should give you essentially the same functionality as you'd get from OS/2, Windows or MacOS.

Also kind of neat is the Universal Printer Description Format (UPDF) being worked on over at The Printer Working Group's web site. I've met with them and it seems like they are a clever bunch of people who do printing for a living trying to set aside corporate differences to come up with a standard that will benefit us all. They've mumbled stuff about CUPS to me and waved their hands vaguely but it seems to me that CUPS doesn't go nearly far enough toward fixing what's wrong with UNIX printing.

YMMV.

To quote the IPP ftp://ftp.pwg.org/pub/pwg/ ipp/new_REQ/ipp-req-981116.txt "Driver here refers to the code installed in some client operating system to generate the print data stream for the intended printer. The actual details for installing a printer driver are operating system dependent and are also outside the scope of IPP. However, an IPP printer or a directory service advertising an IPP Printer should be capable of telling a client what drivers are available and /or required, where they can be found, and provide pointers to installation instructions, installation code or initialization strings required to install the driver. See section 4.1 (SECURITY CONSIDERATIONS) for security implications of driver download and installation."

Am I missing something here?

IPP in concept may be a good idea and we may well find ourselves shipping things to Kinko's for output in the future. Why not use PostScript instead of creating a whole new markup language that will no doubt end up with vendor-specific rendering issues similar to current web browsers? Anyone who has tried to make a webpage look good cross-platform/cross-browser knows what I am talking about...

Save your flames about PostScript being a proprietary architechture; one of the things Adobe has been able to pull off with PostScript is a standard for printing that you can send anywhere and obtain predictable results in the output, which is exactly what I would want if I were sending output to a client as described in Brice's hypothetical situation.

Reading the CNN piece made me very hostile to this idea. Reading some of the documents on www.pwg.org made me less so. These guys are doing some genuinely clueful stuff in this protocol, and it's worth reading.

I do find some of their choices puzzling. For example, the FAQ dismisses the BSD LPR protocol as ``proprietary'' and therefore unusable. (Hello? By what bizarro definition of ``proprietary'' does 4.4BSD qualify?) They reject RFC 1179 because it's not an Internet standard, and then adopt SSL3 for security, even though it does not seem to be any more official in the IETF sense. A lot of the work seems to be more ad-hoc than they're willing to let on.

Other posters have noted that complex protocols are difficult to do right, and especially difficult to do securely. That's going to be a major problem right there. But overall, an IETF-blessed effort toward an open standard for network printing that includes participation from hardware vendors is probably going to be a good thing in the long run.

Here's the URL of the doc that maps the IPP to LPD protocol:
ftp://ftp.pwg.org/pub/pwg/ ipp/new_PRO/ipp-lpd-981116.txt

There are some differences. LPD has a few features IPP doesn't (some of them outdated), and IPP supports things LPD doesn't.

The links above are just for the IPP URL naming convention. Check out http://www.pwg.org/ipp/ for a full list of documents that are available.


Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com

The 1.0 IPP specifications are available in PDF or in TXT formats. I'll post more once I've read them myself...




Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com

The 1.0 IPP specifications are available in PDF or in TXT formats. I'll post more once I've read them myself...




Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com