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
