Re: Media or paper tray selection in FOP
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
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: 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
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
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
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-landscapefalse/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-landscapetrue/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
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
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
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
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
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
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
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
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
