You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/05/09 12:09:16 UTC

Media or paper tray selection in FOP

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


Re: Media or paper tray selection in FOP

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> We can throw exceptions if no mapping is found, or the stuff is simply
> printed on the default paper and people will quickly figure out that
> they've done something wrong.

Well, having printed large documents on partly manually fed
special paper I know that even small errors can be expensive
in both wasted time and raw material. Raising a warning which
can be upgraded to an error after analyzing the the
layout-master-set in case some mappings aren't found seems to
be prudent (some simple may be left unused).

Well, I've been persuaded that output media control should be
done on the page master level. I'm still somewhat uneasy with
the chain of indirections/mappings necessary, these things tend
to break unexpectedly. But I don't have a better solution either.

J.Pietschmann

Re: Media or paper tray selection in FOP

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 09.05.2006 23:57:24 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Attention: long post. :-)
> [snip stuff which reminds me on reinventing TeX/DVI]
> 
> Using the page master name to map onto output media suggests that
> different page flows could be printed on different media. Is this
> correct?

Yes. The clue about the whole thing is that you even need to print some
pages (for example the last in a flow/page-sequence) onto different
paper. Best example you will also know about: Invoice with an ESR at the
end.

> I don't like the idea of using the name of single-page-masters
> all that much: people with complicated  page sequence masters
> may easily forget to map one of the used single page masters
> properly.

We can throw exceptions if no mapping is found, or the stuff is simply
printed on the default paper and people will quickly figure out that
they've done something wrong.

> I'd rather go for declaring the desired output directly
> on the flow (using an extension attribute), on fo:root for providing
> a default or in a fo:declarations (extension element). 

On the flow or on root you cannot do fine-grained control over which
page is printed on which paper. See example above.

> PIs are
> also an option, they may enhance portability (ignored by other
> software than the target processor) but may confuse users about
> the scope where they apply and may provide surprises if read
> too late in a streaming processing mode.

Unsupported namespace should also be ignored by the processor. The XSL
spec is very clear about the use of non-XSL namespaces. I think when we
start using PIs the whole thing gets even more complicated.


Jeremias Maerki


Re: Media or paper tray selection in FOP

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Attention: long post. :-)
[snip stuff which reminds me on reinventing TeX/DVI]

Using the page master name to map onto output media suggests that
different page flows could be printed on different media. Is this
correct?
I don't like the idea of using the name of single-page-masters
all that much: people with complicated  page sequence masters
may easily forget to map one of the used single page masters
properly. I'd rather go for declaring the desired output directly
on the flow (using an extension attribute), on fo:root for providing
a default or in a fo:declarations (extension element). PIs are
also an option, they may enhance portability (ignored by other
software than the target processor) but may confuse users about
the scope where they apply and may provide surprises if read
too late in a streaming processing mode.

J.Pietschmann

Re: Media or paper tray selection in FOP

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 09.05.2006 17:13:40 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > On 09.05.2006 16:04:37 Chris Bowditch wrote:
> > 
> >>Jeremias Maerki wrote:
> >>
> >>
> >>>On 09.05.2006 13:35:11 Chris Bowditch wrote:
> 
<snip/>
> > This renderer configuration is still implemented as an extension. It's
> > just that the extension is not only about media selection but about
> > configuring the whole renderer which makes the whole thing more
> > universal. Same config layout for both FO-origin configuration and
> > engine-origin configuration.
> 
> What I meant is this sounds awkward to setup. Perhaps if I could see 
> some examples....

ok, I'll try. From a userconfig.xml:

  [..]
  <renderers>
    <renderer mime="application/postscript">
      <auto-rotate-landscape>false</auto-rotate-landscape>
      <printer-setup name="Xerox DocuPrint 180"> 
        <printer-def src="printer-defs/xerox-dp180.xml"/>
        <media-map>
          <media master="form1" media-type="form1"/>
          <media master="letterhead" media-type="letterhead"/>
          <media master="plain" media-type="plain"/>
        </media-map>
      </printer-setup>
      <printer-setup name="Lexmark Optra T614">
        <printer-def media-selection="mediapos">
          <paper-source name="Upper" mediapos="1"/>
          <paper-source name="Manual" mediapos="2"/>
          <paper-source name="Lower" mediapos="4"/>
        </printer-def>
        <media-map>
          <media master="form1" paper-source="Manual"/>
          <media master="letterhead" paper-source="Upper"/>
          <media master="plain" paper-source="Lower"/>
        </media-map>
      </printer-setup>
      <fonts>
        <font metr......
  [..]

In your FO file:

<fo:root [..] ps:printer="HP LJ8000">
  <fo:layout-master-set [..]>
    [..]
  </fo:layout-master-set>
  <fo:declarations>
    <ps:renderer-configuration>
      <ps:auto-rotate-landscape>true</ps:auto-rotate-landscape>
      <printer-setup name="HP LJ8000">
        <printer-def media-selection="mediapos">
          <paper-source name="Upper" mediapos="1"/>
          <paper-source name="Manual" mediapos="2"/>
          <paper-source name="Lower" mediapos="4"/>
          <paper-source name="LargeCapacity" mediapos="5"/>
        </printer-def>
        <media-map>
          <media master="form1" paper-source="Upper"/>
          <media master="letterhead" paper-source="Lower"/>
          <media master="plain" paper-source="LargeCapacity"/>
        </media-map>
      </printer-setup>
      
      <ps:fonts> <!-- adds additional fonts to the setup above if you want -->
        [..]
      </ps:font
    <ps:renderer-configuration>
  </fo:declarations>

Essentially, I'm splitting up the printer-setup into two parts:
printer-def contains the minimum info that would otherwise be found in a
PPD. It can either be inlined, or referenced by a URI for easy reuse.
The media-map defines the mapping between master-names and the media
selection code. Like this it defines the concrete setup of a particular
printer.

The ps:printer attribute on fo:root selects the concrete printer setup
for the document. I imagine this setting can also come from Java code as
a renderer option, depending on whether you prefer to control the whole
thing from the XML side or from the Java side.

Of course, the renderer-configuration element can also be included in
the IF, much like the ps:ps-setup-code extension element.

I've implemented something similar about 4 years ago, although for a
PostScript post-processing component. However, this already incorporates
lessons learned back then, although the example above is not complete.
There are printers which don't like the InputAttributes dictionary, for
example. This is not shown here.

> > 
> > 
> >>because the user has 2 steps to achieve tray selection instead of one.
> > 
> > 
> > I don't see two steps. The master-name is there anyway. If you're going
> > for hard-coded trays or media names is simply a choice (or depends on
> > the printer model). Maybe you see the media name to tray mapping as the
> > second step, but that's something that many operators do anyway.
> 
> By 2 steps I meant:
> 
> 1) the user creates a master name to media name mapping in the 
> configuration file
> 2) For some documents it's necessary to create an alternative 
> configuration in the FO or IF XML overriding the file.

Ah, I see.

> > 
> > 
> >>Isn't the objective behind your proposal to make life easier for the user?
> > 
> > 
> > Absolutely. By hiding implementation details from him. The current PS
> > extension requires quite a bit of knowledge about PostScript.
> > 
> > I think we also have to be aware that not everyone is going to work with
> > the IF. Hey, Chris, you're a power-user! 
> 
> :) True, I guess.
> 
> > Not everyone is. I'm trying to
> > address that but I'm not sure I'm succeeding. Maybe I want too much once
> > more, while something easy such as the existing PS extension is
> > everything people need. The equivalent to that for PCL would probably be
> > a simple extension attribute on simple-page-master: pcl:paper-source="1"
> > to select the upper tray as per the printer's documentation. If people
> > prefer that, ok. It's certainly less work than what I have in mind.
> 
> Well, that's my preference, but let's see what some of the other 
> committers think. I'm certainly happy to compromise and make it slightly 
> harder for power users if it makes it a bit easier for regular users.

I'll let the above sink in a little. It's probably a little more work
than I expected at first to implement the above system. After some good
night's sleep I think it's probably best to simply use the most simple
system for now and do the luxury version when there's concrete demand.
:-)


Jeremias Maerki


Re: Media or paper tray selection in FOP

Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:

> On 09.05.2006 16:04:37 Chris Bowditch wrote:
> 
>>Jeremias Maerki wrote:
>>
>>
>>>On 09.05.2006 13:35:11 Chris Bowditch wrote:

<snip/>

>>
>>Yes I agree that /MediaType is the most widely used way, but we have 
>>customers out there using /MediaPosition too. The bit I don't understand 
>>in your proposal is how the configuration file will specify exactly 
>>which will be used. I thought you were saying it would be hard coded to 
>>/MediaType, and only the media name would be fetched from the configuration.
> 
> 
> I did not say how exactly I would design the configuration. I think
> that's step 2. Given what you said earlier I assume only supporting
> /MediaType will not be enough. I should have figured that out myself.

True, it was just implied. And yes supporting just /MediaType is not 
good enough.

> 
> 
>>>>I also think this is a little bit Out of Scope for FOP. FOP should 
>>>>provide some means to achieve tray selection via the Extension element 
>>>>mechanism, but providing master name to media name mapping in the 
>>>>configuration along with making assumptions about the Postscript and PCL 
>>>>to be inserted into the output is going a step too far I think.
>>>
>>>
>>>Sorry Chris, but the additional logic needed for that is trivial. I
>>>don't see why this alone would make it out of scope.
>>
>>Maybe, but parsing PPD files is definitely Out of Scope for XSL-FO and 
>>FOP IMHO. Of course, that alone is not a reason not to do it.
> 
> 
> Another misunderstanding, sorry. I didn't plan on implementing PPD
> parsing. I consider that too much work for too little gain. I want to
> make this as simple as possible, but still as flexible as possible.

Cool, thats my objective too :)

<snip/>

> This renderer configuration is still implemented as an extension. It's
> just that the extension is not only about media selection but about
> configuring the whole renderer which makes the whole thing more
> universal. Same config layout for both FO-origin configuration and
> engine-origin configuration.

What I meant is this sounds awkward to setup. Perhaps if I could see 
some examples....

> 
> 
>>because the user has 2 steps to achieve tray selection instead of one.
> 
> 
> I don't see two steps. The master-name is there anyway. If you're going
> for hard-coded trays or media names is simply a choice (or depends on
> the printer model). Maybe you see the media name to tray mapping as the
> second step, but that's something that many operators do anyway.

By 2 steps I meant:

1) the user creates a master name to media name mapping in the 
configuration file
2) For some documents it's necessary to create an alternative 
configuration in the FO or IF XML overriding the file.

> 
> 
>>Isn't the objective behind your proposal to make life easier for the user?
> 
> 
> Absolutely. By hiding implementation details from him. The current PS
> extension requires quite a bit of knowledge about PostScript.
> 
> I think we also have to be aware that not everyone is going to work with
> the IF. Hey, Chris, you're a power-user! 

:) True, I guess.

> Not everyone is. I'm trying to
> address that but I'm not sure I'm succeeding. Maybe I want too much once
> more, while something easy such as the existing PS extension is
> everything people need. The equivalent to that for PCL would probably be
> a simple extension attribute on simple-page-master: pcl:paper-source="1"
> to select the upper tray as per the printer's documentation. If people
> prefer that, ok. It's certainly less work than what I have in mind.

Well, that's my preference, but let's see what some of the other 
committers think. I'm certainly happy to compromise and make it slightly 
harder for power users if it makes it a bit easier for regular users.

Chris



Re: Media or paper tray selection in FOP

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 09.05.2006 16:04:37 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > On 09.05.2006 13:35:11 Chris Bowditch wrote:
<snip/>
> >>As you've already mentioned in PS there is more than one way of 
> >>specifying tray selection. So assuming one particular way (/MediaType) 
> >>would be rather limiting in my opinion and not desirable. Perhaps you 
> >>didn't mean that, but that is my understanding of what you said.
> > 
> > 
> > You got me wrong. The /MediaType way is actually the most flexible and
> > most standard way for high volume printers. The printer operator can
> > adjust the tray setup and select the target printer as he likes right
> > before printing.
> 
> Yes I agree that /MediaType is the most widely used way, but we have 
> customers out there using /MediaPosition too. The bit I don't understand 
> in your proposal is how the configuration file will specify exactly 
> which will be used. I thought you were saying it would be hard coded to 
> /MediaType, and only the media name would be fetched from the configuration.

I did not say how exactly I would design the configuration. I think
that's step 2. Given what you said earlier I assume only supporting
/MediaType will not be enough. I should have figured that out myself.

> >>I also think this is a little bit Out of Scope for FOP. FOP should 
> >>provide some means to achieve tray selection via the Extension element 
> >>mechanism, but providing master name to media name mapping in the 
> >>configuration along with making assumptions about the Postscript and PCL 
> >>to be inserted into the output is going a step too far I think.
> > 
> > 
> > Sorry Chris, but the additional logic needed for that is trivial. I
> > don't see why this alone would make it out of scope.
> 
> Maybe, but parsing PPD files is definitely Out of Scope for XSL-FO and 
> FOP IMHO. Of course, that alone is not a reason not to do it.

Another misunderstanding, sorry. I didn't plan on implementing PPD
parsing. I consider that too much work for too little gain. I want to
make this as simple as possible, but still as flexible as possible.

> > 
> > Just an idea: How about we generalize the whole thing and allow to
> > specify the renderer configuration as an extension element in FO and IF
> > (intermediate format). The renderer is configured using Avalon
> > Configuration normally through the RendererFactory. If after starting
> > the renderer an extension element is received with some additional renderer
> > configuration you can simply overload the existing configuration. Should
> > not be hard to achieve.
> 
> That's better, but still not as good as extension elements,

This renderer configuration is still implemented as an extension. It's
just that the extension is not only about media selection but about
configuring the whole renderer which makes the whole thing more
universal. Same config layout for both FO-origin configuration and
engine-origin configuration.

> because the user has 2 steps to achieve tray selection instead of one.

I don't see two steps. The master-name is there anyway. If you're going
for hard-coded trays or media names is simply a choice (or depends on
the printer model). Maybe you see the media name to tray mapping as the
second step, but that's something that many operators do anyway.

> Isn't the objective behind your proposal to make life easier for the user?

Absolutely. By hiding implementation details from him. The current PS
extension requires quite a bit of knowledge about PostScript.

I think we also have to be aware that not everyone is going to work with
the IF. Hey, Chris, you're a power-user! Not everyone is. I'm trying to
address that but I'm not sure I'm succeeding. Maybe I want too much once
more, while something easy such as the existing PS extension is
everything people need. The equivalent to that for PCL would probably be
a simple extension attribute on simple-page-master: pcl:paper-source="1"
to select the upper tray as per the printer's documentation. If people
prefer that, ok. It's certainly less work than what I have in mind.


Jeremias Maerki


Re: Media or paper tray selection in FOP

Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:

> On 09.05.2006 13:35:11 Chris Bowditch wrote:

<snip/>

>>
>>I'm sorry Jeremias, your arguments here have failed to convince me that 
>>your suggested approach is the best way. I'm still in favour of using 
>>extension elements for PS, PCL and AFP. It should be possible to add the 
>>extension elements into the Intermediate Format XML, as the printer to 
>>be used may not be known until later in the processing (as you already 
>>suggested and that bit I agree with)
> 
> 
> Ok. Maybe this gives a new light into the whole topic: renderer
> configuration vs. extension in XSL-FO. Namely, because you highlight the
> third possibility that the extension elements may be injected in the
> intermediate format rather than the XSL-FO.

:) This is how our system works today. The IF XML to PS step is left 
until the last possible moment when the Printer is known. Just prior to 
conversion, printer specific commands can be inserted into the IF XML.

> 
> 
>>If the master name to media name mapping is placed in the configuration 
>>file then there is no means to override it for a single document.
> 
> 
> Right.
> 
> 
>>After 
>>all there is only 1 configuration file, and it cannot be changed at 
>>runtime.
> 
> 
> Nope. You can can do custom configuration for a single renderer instance
> if you like. No problem.

True, but far less convenient than specifying an extension element.

> 
> 
>>Allowing extension elements in the IF XML is the most flexible 
>>way. Then you don't need to know the printer when working in XSLT and 
>>FO, but when the IF XML is processed the destination printer should be 
>>known. (It is in our system anyway :)
> 
> 
> Ok, that's a way to approach it I did not think about. In the systems I
> built, the renderer configuration would always have been sufficient.
> 
> 
>>As you've already mentioned in PS there is more than one way of 
>>specifying tray selection. So assuming one particular way (/MediaType) 
>>would be rather limiting in my opinion and not desirable. Perhaps you 
>>didn't mean that, but that is my understanding of what you said.
> 
> 
> You got me wrong. The /MediaType way is actually the most flexible and
> most standard way for high volume printers. The printer operator can
> adjust the tray setup and select the target printer as he likes right
> before printing.

Yes I agree that /MediaType is the most widely used way, but we have 
customers out there using /MediaPosition too. The bit I don't understand 
in your proposal is how the configuration file will specify exactly 
which will be used. I thought you were saying it would be hard coded to 
/MediaType, and only the media name would be fetched from the configuration.

> 
> 
>>I also think this is a little bit Out of Scope for FOP. FOP should 
>>provide some means to achieve tray selection via the Extension element 
>>mechanism, but providing master name to media name mapping in the 
>>configuration along with making assumptions about the Postscript and PCL 
>>to be inserted into the output is going a step too far I think.
> 
> 
> Sorry Chris, but the additional logic needed for that is trivial. I
> don't see why this alone would make it out of scope.

Maybe, but parsing PPD files is definitely Out of Scope for XSL-FO and 
FOP IMHO. Of course, that alone is not a reason not to do it.

> 
> Just an idea: How about we generalize the whole thing and allow to
> specify the renderer configuration as an extension element in FO and IF
> (intermediate format). The renderer is configured using Avalon
> Configuration normally through the RendererFactory. If after starting
> the renderer an extension element is received with some additional renderer
> configuration you can simply overload the existing configuration. Should
> not be hard to achieve.

That's better, but still not as good as extension elements, because the 
user has 2 steps to achieve tray selection instead of one. Isn't the 
objective behind your proposal to make life easier for the user?

Thanks for clarification,

Chris



Re: Media or paper tray selection in FOP

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 09.05.2006 13:35:11 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> <snip/>
> 
> > 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.
> 
> I'm sorry Jeremias, your arguments here have failed to convince me that 
> your suggested approach is the best way. I'm still in favour of using 
> extension elements for PS, PCL and AFP. It should be possible to add the 
> extension elements into the Intermediate Format XML, as the printer to 
> be used may not be known until later in the processing (as you already 
> suggested and that bit I agree with)

Ok. Maybe this gives a new light into the whole topic: renderer
configuration vs. extension in XSL-FO. Namely, because you highlight the
third possibility that the extension elements may be injected in the
intermediate format rather than the XSL-FO.

> If the master name to media name mapping is placed in the configuration 
> file then there is no means to override it for a single document.

Right.

> After 
> all there is only 1 configuration file, and it cannot be changed at 
> runtime.

Nope. You can can do custom configuration for a single renderer instance
if you like. No problem.

> Allowing extension elements in the IF XML is the most flexible 
> way. Then you don't need to know the printer when working in XSLT and 
> FO, but when the IF XML is processed the destination printer should be 
> known. (It is in our system anyway :)

Ok, that's a way to approach it I did not think about. In the systems I
built, the renderer configuration would always have been sufficient.

> As you've already mentioned in PS there is more than one way of 
> specifying tray selection. So assuming one particular way (/MediaType) 
> would be rather limiting in my opinion and not desirable. Perhaps you 
> didn't mean that, but that is my understanding of what you said.

You got me wrong. The /MediaType way is actually the most flexible and
most standard way for high volume printers. The printer operator can
adjust the tray setup and select the target printer as he likes right
before printing.

> I also think this is a little bit Out of Scope for FOP. FOP should 
> provide some means to achieve tray selection via the Extension element 
> mechanism, but providing master name to media name mapping in the 
> configuration along with making assumptions about the Postscript and PCL 
> to be inserted into the output is going a step too far I think.

Sorry Chris, but the additional logic needed for that is trivial. I
don't see why this alone would make it out of scope.

Just an idea: How about we generalize the whole thing and allow to
specify the renderer configuration as an extension element in FO and IF
(intermediate format). The renderer is configured using Avalon
Configuration normally through the RendererFactory. If after starting
the renderer an extension element is received with some additional renderer
configuration you can simply overload the existing configuration. Should
not be hard to achieve.

Jeremias Maerki


Re: Media or paper tray selection in FOP

Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:

<snip/>

> 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.

I'm sorry Jeremias, your arguments here have failed to convince me that 
your suggested approach is the best way. I'm still in favour of using 
extension elements for PS, PCL and AFP. It should be possible to add the 
extension elements into the Intermediate Format XML, as the printer to 
be used may not be known until later in the processing (as you already 
suggested and that bit I agree with)

If the master name to media name mapping is placed in the configuration 
file then there is no means to override it for a single document. After 
all there is only 1 configuration file, and it cannot be changed at 
runtime. Allowing extension elements in the IF XML is the most flexible 
way. Then you don't need to know the printer when working in XSLT and 
FO, but when the IF XML is processed the destination printer should be 
known. (It is in our system anyway :)

As you've already mentioned in PS there is more than one way of 
specifying tray selection. So assuming one particular way (/MediaType) 
would be rather limiting in my opinion and not desirable. Perhaps you 
didn't mean that, but that is my understanding of what you said.

I also think this is a little bit Out of Scope for FOP. FOP should 
provide some means to achieve tray selection via the Extension element 
mechanism, but providing master name to media name mapping in the 
configuration along with making assumptions about the Postscript and PCL 
to be inserted into the output is going a step too far I think.

Chris



Re: Media or paper tray selection in FOP

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 12.05.2006 09:50:01 mm wrote:
> > Simon Pepping wrote:
> >
> <snip/>
> >>
> >> Regarding a configuration file per printing run, recently a similar
> >> possibility was put forward for the user preferences for
> >> printer-specific image handling and other options. In a recent
> >> fop-user post I suggested the idea of hyphenation exceptions in a
> >> configuration file.
> >
> > I agree hyphenation exceptions should belong in a configuration file. I
> > would imagine that once the exceptions have been worked out they will
> > remain constant for a long time and will not change between documents,
> > like media selection can.
> >
> 
> Although I had some offline IM discussions with Jeremias on this topic I
> have kept quiet so far just observing how things are moving.
> 
> However, I now feel the need to comment from a developers point of view,
> i.e. a developer who uses fop in high volume backend business processes.
> 
> If I would have to deal with creating per document config files that would
> simply be a nightmare. IMO anything that is likely to need configuration
> on a per document basis need to be either with the document (e.g. fo
> extensions) or settable via an API but it should not be required to be in
> a config file.

Agreed.

> Regarding the dislike of extensions voiced here I am not so concerned with
> XSL-FO purity. In my observations XSL-FO is very rarely used as the raw
> data interchange format. Most enviroments use a combination of custom XML
> inputs and custom XSL stylesheets and the actual fo file is hardly ever
> seen. Just look in the fop-user list - most people submit XML/XSL snippets
> and only after explicit prompting do we get the actual fo.

Agreed.

> Therefore as a developer if I need to use a feature outside of XSL-FO,
> e.g. media selection, I have to use what ever the actual fo processor
> provides. This means I have to make changes when I switch between XEP /
> RenderX / FOP for example. My first preference here would be to just have
> to adapt the XSL and leave the rest unchanged. Obviously because we don't
> have a standard XSL-FO API I have to change code as well. However, once I
> have a wrapper in place which allows me to plug-in different FO processors
> there should not be a need to even change that.

Uhm, actually we could have a standard XSL-FO API (if I understand you
correctly), at least for Java, if we took my JAXG proposal, gathered
support from other FO processors and started a JSR to standardize it.
However, you will only be able to define a subset of all features as a
standard in such a wrapper API. The functionality offered by the various
tools vary enormously. I have neglected this thing a little lately. I
guess I should do some cleanup and publish an updated version because
I've made quite some detail improvements compared to the published
version.

> So a simplified summary of my view:
> 
> 1. Put into the config file everything that is expected to be fixed within
> a typical XSL-FO processing environment and yes, having a small number of
> different config files is fine as well.

Agreed.

> 2. Put into extensions anything that is typically managed per document and
> likely to be different between documents.

Agreed.

> And yes there will be grey areas and yes having some abstraction / mapping
> between generic values in an fo extension and specific values in a config
> file is fine with me. For example if we have <simple-page-master ...
> fox:media-type="xxx" /> and then in the config file entries which map
> "xxx" to some media selection specific data per renderer that should be
> OK.

Here's where I'm uneasy about a detail. fox:media-type suggest an
abstract name for a media type which needs to be mapped later on. I
believe it's simpler to just use the master-name which is already
available and easily fits the requirements to serve as an abstract media
type name.

I'd like to try to sum up what we get out of this thread in addition to
your summary:
- My mapping idea is probably overkill. We should try to keep things at
a minimum and only expand if there's real need. AFAIK, the PostScript
infrastructure is good enough for now and a simple extension attribute
for PCL should be enough to select the paper source using the effective
integer value for the device-specific tray. What this means for AFP, I
cannot tell, yet. Such a simple way of controlling the media selection
is certainly within the scope of FOP IMO.
- My idea with having the engine configuration in the FO file in
addition to the programmatically supplied one is probably overkill, too.

Derived from the above, here's what I'm going to do:
- I'll implement the extension attribute on simple-page-master for PCL
so the user can specify the effective paper tray which he has to figure
out himself. The attribute will be optional, of course.
- Nothing else in this area for the moment. If additional requirements
come up I'll deal with that when it's time.


Jeremias Maerki


Re: Media or paper tray selection in FOP

Posted by Chris Bowditch <bo...@hotmail.com>.
Simon Pepping wrote:

> Hi,
> 
> I read the long discussion between Jeremias and Chris, and Jörg's
> note.
> 
> I do not like the idea of extension elements. I think, here I refer
> back to a recent post by Glen about standard FO files. I like the idea
> of a configuration file. Even a different configuration file for each
> single document is not a bad thing, possibly in addition to a more
> permanent configuration file with more permanent data like
> fonts. Surely most users do not like to write a configuration file
> often, but maybe someone can write a GUI for them to fire off FOP with
> the desired configuration.

This sounds like it could be hard work for the user. I don't like this 
approach for that reason.

> 
> I also have a feeling of reinvention, not of TeX/DVI, but of the
> wheel. I do not know really much about printing. But I imagine this
> procedure. When I ask an application like Acrobat to print a file, it
> pops up a dialog. The dialog reads a printer capabilities file, as a
> PPD file or from the printer driver or from some other source. So the
> user makes a choice and the application inserts the appropriate
> commands for the user's choice into the output file. FOP is such a
> application, so that is what it should do. Do all these applications
> do the work themselves? I do not think so. They use a framework. Isn't
> Java's framework the Java Printing System? So FOP should use that.

You are right FOP should not be concerning itself with the details of 
Printing and that should be left to an external system. However media 
selection cannot be determined without some input from the user. IMO, 
these hints should live in the FO file, but they should be minimal and 
not the entire configuration as Jeremias was suggesting.

> 
> So definitely a configuration external to the FO file. And something
> like the Java Printing System to know the installed printer
> configuration and provide the user with the appropriate GUI and
> choice.

Well, its not always possible to show a GUI. That might work well for 
Acrobat, but when FOP is used in a Batch Processing engine running on a 
Unix server how will it prompt the user for media selection?

> 
> Regarding a configuration file per printing run, recently a similar
> possibility was put forward for the user preferences for
> printer-specific image handling and other options. In a recent
> fop-user post I suggested the idea of hyphenation exceptions in a
> configuration file.

I agree hyphenation exceptions should belong in a configuration file. I 
would imagine that once the exceptions have been worked out they will 
remain constant for a long time and will not change between documents, 
like media selection can.

Chris



Re: Media or paper tray selection in FOP

Posted by Simon Pepping <sp...@leverkruid.eu>.
On Fri, May 12, 2006 at 03:50:01PM +0800, mm@arcus.com.au wrote:
> > Simon Pepping wrote:
> >
> However, I now feel the need to comment from a developers point of view,
> i.e. a developer who uses fop in high volume backend business processes.
> 
> If I would have to deal with creating per document config files that would
> simply be a nightmare. IMO anything that is likely to need configuration
> on a per document basis need to be either with the document (e.g. fo
> extensions) or settable via an API but it should not be required to be in
> a config file.

Configuration in FOP is settable via an API.
 
> Regarding the dislike of extensions voiced here I am not so concerned with
> XSL-FO purity. In my observations XSL-FO is very rarely used as the raw
> data interchange format. Most enviroments use a combination of custom XML
> inputs and custom XSL stylesheets and the actual fo file is hardly ever
> seen. Just look in the fop-user list - most people submit XML/XSL snippets
> and only after explicit prompting do we get the actual fo.

Many people get their FO files via standard XSLT stylesheets, like the
docbook stylesheets. It is the FO standard that makes them possible,
but they already have renderer specific sections. No need to add more
to those sections.
 
This discussion is about a topic about which I do not know very much,
viz. printer specific commands in a printer file. Maybe I am making
noise about nothing. But I do not fancy the idea of extension elements
that do not add much desired layout extensions, such as the bookmarks
did.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: Media or paper tray selection in FOP

Posted by mm...@arcus.com.au.
> Simon Pepping wrote:
>
<snip/>
>>
>> Regarding a configuration file per printing run, recently a similar
>> possibility was put forward for the user preferences for
>> printer-specific image handling and other options. In a recent
>> fop-user post I suggested the idea of hyphenation exceptions in a
>> configuration file.
>
> I agree hyphenation exceptions should belong in a configuration file. I
> would imagine that once the exceptions have been worked out they will
> remain constant for a long time and will not change between documents,
> like media selection can.
>

Although I had some offline IM discussions with Jeremias on this topic I
have kept quiet so far just observing how things are moving.

However, I now feel the need to comment from a developers point of view,
i.e. a developer who uses fop in high volume backend business processes.

If I would have to deal with creating per document config files that would
simply be a nightmare. IMO anything that is likely to need configuration
on a per document basis need to be either with the document (e.g. fo
extensions) or settable via an API but it should not be required to be in
a config file.

Regarding the dislike of extensions voiced here I am not so concerned with
XSL-FO purity. In my observations XSL-FO is very rarely used as the raw
data interchange format. Most enviroments use a combination of custom XML
inputs and custom XSL stylesheets and the actual fo file is hardly ever
seen. Just look in the fop-user list - most people submit XML/XSL snippets
and only after explicit prompting do we get the actual fo.

Therefore as a developer if I need to use a feature outside of XSL-FO,
e.g. media selection, I have to use what ever the actual fo processor
provides. This means I have to make changes when I switch between XEP /
RenderX / FOP for example. My first preference here would be to just have
to adapt the XSL and leave the rest unchanged. Obviously because we don't
have a standard XSL-FO API I have to change code as well. However, once I
have a wrapper in place which allows me to plug-in different FO processors
there should not be a need to even change that.

So a simplified summary of my view:

1. Put into the config file everything that is expected to be fixed within
a typical XSL-FO processing environment and yes, having a small number of
different config files is fine as well.

2. Put into extensions anything that is typically managed per document and
likely to be different between documents.

And yes there will be grey areas and yes having some abstraction / mapping
between generic values in an fo extension and specific values in a config
file is fine with me. For example if we have <simple-page-master ...
fox:media-type="xxx" /> and then in the config file entries which map
"xxx" to some media selection specific data per renderer that should be
OK.

> Chris
>

Manuel



Re: Media or paper tray selection in FOP

Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, May 11, 2006 at 08:55:24AM +0100, Chris Bowditch wrote:
> Simon Pepping wrote:
> 
> >So definitely a configuration external to the FO file. And something
> >like the Java Printing System to know the installed printer
> >configuration and provide the user with the appropriate GUI and
> >choice.
> 
> Well, its not always possible to show a GUI. That might work well for 
> Acrobat, but when FOP is used in a Batch Processing engine running on a 
> Unix server how will it prompt the user for media selection?

Therefore it should also be possible to make the choice by a
configuration file, or perhaps by way of command line options.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: Media or paper tray selection in FOP

Posted by Simon Pepping <sp...@leverkruid.eu>.
Hi,

I read the long discussion between Jeremias and Chris, and Jörg's
note.

I do not like the idea of extension elements. I think, here I refer
back to a recent post by Glen about standard FO files. I like the idea
of a configuration file. Even a different configuration file for each
single document is not a bad thing, possibly in addition to a more
permanent configuration file with more permanent data like
fonts. Surely most users do not like to write a configuration file
often, but maybe someone can write a GUI for them to fire off FOP with
the desired configuration.

I also have a feeling of reinvention, not of TeX/DVI, but of the
wheel. I do not know really much about printing. But I imagine this
procedure. When I ask an application like Acrobat to print a file, it
pops up a dialog. The dialog reads a printer capabilities file, as a
PPD file or from the printer driver or from some other source. So the
user makes a choice and the application inserts the appropriate
commands for the user's choice into the output file. FOP is such a
application, so that is what it should do. Do all these applications
do the work themselves? I do not think so. They use a framework. Isn't
Java's framework the Java Printing System? So FOP should use that.

So definitely a configuration external to the FO file. And something
like the Java Printing System to know the installed printer
configuration and provide the user with the appropriate GUI and
choice.

Regarding a configuration file per printing run, recently a similar
possibility was put forward for the user preferences for
printer-specific image handling and other options. In a recent
fop-user post I suggested the idea of hyphenation exceptions in a
configuration file.

Just my two cents.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu