Re: startPageSequence() in Renderer interface

2007-04-05 Thread Andreas L Delmelle

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

2007-04-04 Thread Jeremias Maerki
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

2007-04-03 Thread Simon Pepping
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


startPageSequence() in Renderer interface

2007-04-02 Thread Adrian Cumiskey

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.