Intelligent Printer Data Stream is technology developed by IBM for conveying content. Output may be to a screen, a printer, or a storage repository. The input is a "document", which is a container for various types of "objects" which are assigned locations on the various pages within the document. An object may be a block of text, a rasterized image such as a photograph or signature, or a line-drawn graphical object such as a mutual fund graph, or a barcode. Documents may be laid out in logical terms, such as there being a letterhead, body, and signature. The object technology itself is called MO:DCA — Mixed Object: Document Content Architecture.
IPDS had its origins in IBM mainframe OS printing. Those who were around in those days will remember that IBM's 1403, 3211, and other line printers supported having a Carriage Control Character as the first byte in each text line. For example, '1' was an order to skip to the top of the next sheet, to start a new page of output. IBM built upon that for IPDS, where the byte defines a command code which specifies a type of structured field, to define actions and content.
To appreciate this, you need to understand PostScript printing. In PostScript, you basically send the job to the printer, and hope for the best. There is no communication to or from the printer during the printing, unless HP's PJL is in use, and then you get only end-of-page and end-of-job indications back from the printer. The host really has no idea what's going on in the printer, and that can lead to a variety of everyday problems, as those of us who deal with PostScript printing have seen. Further, the instructions within the PostScript control what is happening with the job, where inappropriate instructions may screw things up. An example of this is where the PostScript was generated to use Tray 1 on the printer for its paper supply: in an HP printer, Tray 1 is the special pull-down panel feeder, almost never used, and certainly not stocked with paper. A job calling for paper from Tray 1 in HP printing will cause the printer to stop until someone notices and takes action, delaying all printing, possibly for a long time.
With IPDS, there is intimate, bi-directional communication with the (IPDS) printer, as the print server sends the job by pieces to the printer and receives acknowledgements back. If anything goes wrong (e.g., paper jam), the host knows immediately, and can re-send the damaged page. Another distinguishing feature of IPDS printing is that the print server defines what happens during printing. For example: A PostScript job submitted to an IPDS environment print server will be "transformed" into an AFP/MO:DCA file, which will then be sent to the printer. The printer server can discern, by the logical destination name by which the job was submitted, that the job should be printed duplex, and should be stapled. The print server can then cause the duplex printing, and stapling. This kind of job management can nicely "normalize" the printing of jobs, and avoid tray and other issues.