(v13) Interpreting other page description languages

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.

A large number of page description languages and file formats are in common use. For instance:

Printer and plotter control languages. Examples include HPGL (Hewlett Packard plotter language), PCL (Hewlett Packard LaserJet and DeskJet), and Epson ESC/P
Standard file formats: examples include RTF (rich text format), and TIFF (tag image file format)
Proprietary formats such as Scitex CT and LW files
File compression formats such as compress (Unix), pkzip, and lharc
Encodings, such as uuencode or a PC-formatted Type 1 font file

In the case of page description languages, you must have a printer that understands the relevant codes or a conversion program. Files in standard formats are usually imported into applications that understand them, from where they can be printed: there is a conversion algorithm in the application or printer driver. However, with an appropriate filter, files of all these types can be printed directly to the Harlequin RIP.

To process such files through the Harlequin RIP, the contents are normally converted into the PostScript language and then interpreted in the usual way. It is possible to write a device (HHR) or input plugin channel class (HMR) that takes an operating system file or perhaps a source such as a serial line and emits the PostScript-language equivalent of whatever format it contains.

However, this mixes up the two functions of actually acquiring the data and converting that data to the PostScript language. It is much better to acquire the data from an ordinary file opened on whatever device is appropriate (device implementations make no assumptions about what they are reading) and filter the file to convert it into the PostScript language.

This approach also means that methods of acquiring data built into the Harlequin RIP are not wasted—for example, disk access in HMR has been tuned significantly to increase performance. (A possible case for the other approach might be where the filter would require forward references into the data stream it is processing—for example, in a completely general TIFF to PostScript language filter—though judicious generation of setfileposition operators might be able to work around this.)

Consider how this might be done for hypothetical HPGL filter. In HHR where you have control over the %config% device, this is easy: instead of emitting PostScript which provides a file as source of input as in:

... (%serial%)(r) file ...

Instead, apply the filter to it:

... (%serial%) (r) file /HPGLDecode filter ...

In HMR, you could use a page feature. This allows you to have a published PostScript-language compatible printer under one name and a published HPGL-compatible printer under another, an HPGL spool folder, and so on.

A page feature is run after the source of the job has been identified and a file has been opened on it and after any page setup, but before any of the job has actually been interpreted. Therefore, the technique is to switch the file opened for interpretation to a filter applied to it. This requires you to know where the Harlequin RIP stores the file object for the job: it is stdin in serverdict (the output stream is also available, in stdout in serverdict). Therefore, the page feature looks like this:

TEXT

            serverdict begin
            stdin /HPGLDecode filter % open a filter on current input file
            /stdin exch def % replace in serverdict file with
                                    % the new filter
            end

The old version of stdin, and the new version that replaces it, are both literal. The file referred to by stdin is converted to executable by the server loop only just before being executed.

Also, the only relation between stdin in serverdict and the %stdin% pseudo-device is that the file object that stdin refers to is eventually mapped to %stdin% with setstdio, as described in (v13) Mapping standard input and output: setstdio and setstderr. There is nothing special about the name of stdin in this context.

HHR can use a similar technique in a configuration file specified by the command line option -c .

Alternatively, if the source of the job to be interpreted is under your control, you can prefix the job with a minimal fragment of PostScript that operates on the current file. This could apply if you have an HPGL file for example, when the following is tacked on the front:

currentfile /HPGLDecode filter cvx exec

Or for a one-off, you could create a file to print for the purpose which has the name of the HPGL file built into it—remembering the mapping described in (v13) File-name mapping —or even type it directly into the executive:

(%D%HPGLJOBS/AFILE.HPL) (r) file /HPGLDecode filter cvx exec