You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Adrian Cumiskey <ad...@gmail.com> on 2007/04/02 11:05:03 UTC

startPageSequence() in Renderer interface

Hi,

I am working on the postscript renderer and have a query about 
org.apache.fop.render.Renderer#void startPageSequence(LineArea title). 
Its seems a bit wrong to me that this method is invoked with just the 
title of the PageSequence being passed to it, surely it would be better 
to pass the PageSequence itself (which contains the title).  I would 
think that the PageSequence object itself would be much more useful to 
the renderer.  Am I missing something?  Is there a good reason which I 
have missed as to why it is implemented in this way?

Adrian Cumiskey.



Re: startPageSequence() in Renderer interface

Posted by Andreas L Delmelle <a_...@pandora.be>.
On Apr 4, 2007, at 16:42, Adrian Cumiskey wrote:

Hi Adrian / Jeremias,

> <snip />

>>> Speak now or forever hold your peace :-)
>> This is not very helpful, despite the smiley. Besides, things change.
>> Your post is the best example of that. Well, maybe I'm missing a joke
>> not being native English speaking.
>
> I will try to be less playful with my language in future so as to  
> not cause any unnecessary confusion.

Please don't let one misunderstanding hold you back here. If it  
'slips' out as it were, so be it. If someone misunderstands, then  
there is always the possibility for further explanation.

There have been times when I myself caused much worse  
misunderstandings (mainly by /not/ including emoticons). Also, only  
recently, Jeremias himself added a note to a bug which apparently did  
not sit too well with Joe, the Reporter... :-)

I got the drift of the above expression without further explanation  
(and English is not my mother tongue either...)

Freedom of expression is higher up on my list than avoiding  
misunderstandings. (To make the latter work, /everyone/ should keep  
their thoughts to themselves ;-))


Cheers,

Andreas


Re: startPageSequence() in Renderer interface

Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi all,

Jeremias Maerki wrote:
> Hi Adrian
> 
> On 02.04.2007 11:05:03 Adrian Cumiskey wrote:
>> Of course this would mean a change in a low level interface but would be 
>> a trivial change for all our renderers.
> 
> "our" renderers, yes. You also need to consider custom renderer
> developed outside of FOP. If you implement the other method, you can
> simply call the old one and you have a compatible change. But see below...

Yes I am aware of this and I did consider the impact upon custom 
renderers, this is why I raised my query with the dev forum.  Maybe I 
should of added "at least" to the end of that statement to make my 
understanding of the consequences of this change clear.

>> The reason why this is important is that the implementing renderer may 
>> need to do some initial preparation work before page processing (e.g. in 
>> my case the postscript renderer may want to access some extensions that 
>> have been defined as children of the simple page master prior to 
>> processing the individual pages in its sequence).  I don't think I'm 
>> missing something here.. 
> 
> I don't understand the motivation here. The simple page master is
> something that changes from page to page. I'd like to know why you want
> to access something from a page-master in the context of a page-sequence.
> If you had an extension element for PostScript as direct child of
> page-sequence, then I'd understand.

My mistake.  Indeed its the simple page master I am interested in, and I 
have now found a way if implementing what I need to do which requires no 
change to the interface :-).

>> Speak now or forever hold your peace :-)
> 
> This is not very helpful, despite the smiley. Besides, things change.
> Your post is the best example of that. Well, maybe I'm missing a joke
> not being native English speaking.

I will try to be less playful with my language in future so as to not 
cause any unnecessary confusion.  It is a phrase said (for "dramatic 
effect" mostly in movies..) just before two people get married.  Someone 
then in the audience of the ceremony has an opportunity to leap forward 
and object to the action.

Adrian.

Re: startPageSequence() in Renderer interface

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Adrian

On 02.04.2007 11:05:03 Adrian Cumiskey wrote:
> I am working on the postscript renderer and have a query about 
> org.apache.fop.render.Renderer#void startPageSequence(LineArea title). 
> Its seems a bit wrong to me that this method is invoked with just the 
> title of the PageSequence being passed to it, surely it would be better 
> to pass the PageSequence itself (which contains the title).  I would 
> think that the PageSequence object itself would be much more useful to 
> the renderer.  Am I missing something?  Is there a good reason which I 
> have missed as to why it is implemented in this way?

I think the reason for that is that there are simply no other important
things on the PageSequence besides the title. PageSequence.getPageCount
() may not be a reliable source of information during rendering as a
page-sequence can be started without knowing how many pages there will
be in the end. And getPageCount() is really the only thing besides the
title on the PageSequence.

On 03.04.2007 18:25:15 Adrian Cumiskey wrote:
> I have had a good look through the code, changed the interface in my 
> sandbox and I can find no reason why
> 
> org.apache.fop.render.Renderer#void startPageSequence(LineArea title)
> 
> shouldn't instead be
> 
> org.apache.fop.render.Renderer#void 
> startPageSequence(org.apache.fop.area.PageSequence pageSeq).
> 
> Of course this would mean a change in a low level interface but would be 
> a trivial change for all our renderers.

"our" renderers, yes. You also need to consider custom renderer
developed outside of FOP. If you implement the other method, you can
simply call the old one and you have a compatible change. But see below...

> The reason why this is important is that the implementing renderer may 
> need to do some initial preparation work before page processing (e.g. in 
> my case the postscript renderer may want to access some extensions that 
> have been defined as children of the simple page master prior to 
> processing the individual pages in its sequence).  I don't think I'm 
> missing something here.. 

I don't understand the motivation here. The simple page master is
something that changes from page to page. I'd like to know why you want
to access something from a page-master in the context of a page-sequence.
If you had an extension element for PostScript as direct child of
page-sequence, then I'd understand.

> Speak now or forever hold your peace :-)

This is not very helpful, despite the smiley. Besides, things change.
Your post is the best example of that. Well, maybe I'm missing a joke
not being native English speaking.

Jeremias Maerki


Re: startPageSequence() in Renderer interface

Posted by Simon Pepping <sp...@leverkruid.eu>.
On Tue, Apr 03, 2007 at 05:25:15PM +0100, Adrian Cumiskey wrote:
> Hi,
> 
> I have had a good look through the code, changed the interface in my 
> sandbox and I can find no reason why
> 
> org.apache.fop.render.Renderer#void startPageSequence(LineArea title)
> 
> shouldn't instead be
> 
> org.apache.fop.render.Renderer#void 
> startPageSequence(org.apache.fop.area.PageSequence pageSeq).

The title area is special in that it is not part of the page
areas. That is why it has to be passed to the renderer out of
band. The other areas will be passed to the renderer in the process.

In general it is good to pass as little information as needed, to keep
interdependencies to a minimum. "Finding no reason why" is not a good
enough reason to pass more information. The need for the PostScript
renderer to access that information must be good enough to argue for
such a change.

> Of course this would mean a change in a low level interface but would be 
> a trivial change for all our renderers.
> 
> The reason why this is important is that the implementing renderer may 
> need to do some initial preparation work before page processing (e.g. in 
> my case the postscript renderer may want to access some extensions that 
> have been defined as children of the simple page master prior to 
> processing the individual pages in its sequence).  I don't think I'm 
> missing something here..  Speak now or forever hold your peace :-)

Little hope.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: startPageSequence() in Renderer interface

Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi,

I have had a good look through the code, changed the interface in my 
sandbox and I can find no reason why

org.apache.fop.render.Renderer#void startPageSequence(LineArea title)

shouldn't instead be

org.apache.fop.render.Renderer#void 
startPageSequence(org.apache.fop.area.PageSequence pageSeq).

Of course this would mean a change in a low level interface but would be 
a trivial change for all our renderers.

The reason why this is important is that the implementing renderer may 
need to do some initial preparation work before page processing (e.g. in 
my case the postscript renderer may want to access some extensions that 
have been defined as children of the simple page master prior to 
processing the individual pages in its sequence).  I don't think I'm 
missing something here..  Speak now or forever hold your peace :-)

Adrian.

Adrian Cumiskey wrote:
> Hi,
> 
> I am working on the postscript renderer and have a query about 
> org.apache.fop.render.Renderer#void startPageSequence(LineArea title). 
> Its seems a bit wrong to me that this method is invoked with just the 
> title of the PageSequence being passed to it, surely it would be better 
> to pass the PageSequence itself (which contains the title).  I would 
> think that the PageSequence object itself would be much more useful to 
> the renderer.  Am I missing something?  Is there a good reason which I 
> have missed as to why it is implemented in this way?
> 
> Adrian Cumiskey.
> 
> 
>