Attention: long post. :-)
So far FOP does not do any media or paper tray selection in the
supported output formats. Only PostScript output has an extension that
allows to insert PostScript code to do media selection. With the arrival
of PCL and AFP output formats, this topic gains new importance. Both
formats support ways to define either the intended media (AFP) or the
paper tray (PCL).
Last year, I've added the name of the simple-page-master that generates
a page to the page element in the area tree so a renderer can act
according to this information.
To see how other implementations handle this: XEP uses processing
instructions in XSL-FO for PostScript output which is quite equivalent
to FOP's PS extension. I didn't find out how others do this. Most of
them support PDF output only where media selection is a difficult topic.
But supporting job tickets like JDF and such is a topic for another time.
You can see that this is closely related to the recent extension
attribute discussion. Now, what I would like to propose is a general
strategy for FOP to handle media selection. Since we have all the
necessary info (i.e. the name of the generating single-page-master is
enough) we can do the single-page-master to media/paper tray mapping
entirely in the Renderer. The setup will be defined through the
configuration.
Both PostScript and PCL don't have a single way to select the intended
media. PCL printers don't all have the same number and type of paper
trays. PostScript knows at least two different ways to select the
intended output media. Here, it is usually so, that the media name to
actual paper tray mapping is done in the printer/RIP configuration. That
works like this:
XSL-FO: master-name="letterhead"
--> PS: "/MediaType (corp-letterhead)"
--> Printer/RIP: MediaType "corp-letterhead" is mapped to tray 2
--> Printer: takes paper from tray 2
In this example, FOP would have to map the "letterhead" name to the
MediaType "corp-letterhead". Note that in large print shops, the
formatting software sometimes doesn't know on which printer the file
will be printed in the end. In some systems, the formatting is done to
FOP's intermediate format. Only right before printing, the preformatted
documents are concatenated together to a print job by parsing the
intermediate format and using the renderers to create the print job. The
print solution may know the target printer or it may not. In the case of
PostScript it's not that important to know because of the additional
mapping of media types to trays on the printer.
In the case of PCL, this additional mapping step does not exist, so the
printing solution has to know the target printer when the renderer
produce the output file. But that still means that the formatter has to
know which printer the file will be printed on:
XSL-FO: master-name="letterhead"
--> PCL: <ESC>&l4H (Paper Source Command, 4=lower tray)
--> Printer: takes paper from lower tray
How Windows printer drivers solve this: PostScript drivers use a file
called PPD which contains printer specific commands that tell the driver
how to generate the right PS commands to do media selection. PCL drivers
use a similar file type called GPD which essentially does the same.
Parsing these formats is, of course, an option. For PS this is more
realistic than for PCL AFAICS. However, we don't need that kind of
complexity and I don't want spend so much time on this. For PS, it is
most probably sufficient to support the standard "MediaType" approach
which is sufficient for most cases. That will be relatively easy to
implement.The only problem could arise with desktop printers with a
PostScript emulation. Here the media selection is usually done using
"/setpapertray" or with "/MediaPosition" which makes the whole thing
quite similar to the situation with PCL (see next paragraph).
For PCL, it's a little more complicated since the printers differ so
much. There it probably makes sense to support a set of printer
configurations which are either specified inline in the renderer
configuration or an external XML file referenced by an URL. An example
of what information would be defined for a Brother HL-1250 PCL printer:
Trays:
default: 0
upper: 1, use for: * (specifies the default if no other match is found)
manual: 2, use for: letterhead (specifies to use manual feed if a page
with master-name="letterhead" is encountered)
For AFP, the whole thing will probably very similar to the PostScript
approach. AFP supports specifying media names. For the Java Printing
System (when we support it via the Java2DRenderer), the topic will also
arise. I haven't investigated that part, yet.
Conclusion:
Using the master-name approach instead of including printer-specific
commands adds flexibility for media and paper tray selection. The only
thing that will be useful is a parameter to FOP and/or an extension
value in XSL-FO which specifies the actualy printer that the print job
is to be generated for so the renderer can use the right set of mapping
rules.
Jeremias Maerki
