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 15:13:40 GMT
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



Mime
View raw message