Re: Media or paper tray selection in FOP
On 12.05.2006 09:50:01 mm wrote: > > Simon Pepping wrote: > > > > >> > >> 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 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
On Fri, May 12, 2006 at 03:50:01PM +0800, [EMAIL PROTECTED] 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
> Simon Pepping wrote: > >> >> 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 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
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
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
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
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
Re: Media or paper tray selection in FOP
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: > > > 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: [..] false [..] true [..] 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
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
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
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: 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 :) 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
On 09.05.2006 16:04:37 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > On 09.05.2006 13:35:11 Chris Bowditch wrote: > >>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
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. 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
On 09.05.2006 13:35:11 Chris Bowditch wrote: > Jeremias Maerki wrote: > > > > > 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
Jeremias Maerki wrote: 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
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: &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
