xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bowditch <bowditch_ch...@hotmail.com>
Subject Re: Media or paper tray selection in FOP
Date Tue, 09 May 2006 14:04:37 GMT
Jeremias Maerki wrote:

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


>>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.
>>all there is only 1 configuration file, and it cannot be changed at 
> 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,


View raw message