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
