DO NOT REPLY [Bug 47311] [PATCH] Support for bleed, trim and crop box and scaling

2009-06-18 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=47311





--- Comment #3 from Vincent Hennebert vhenneb...@gmail.com  2009-06-18 
04:07:38 PST ---
Hi Peter,

(In reply to comment #2)
 (In reply to comment #1)
  Thanks for this patch, Peter!
  
  I know this is going to be very useful, as questions regarding that
  functionality pop up on the user list from time to time. We'll look into it,
  and will keep you informed. I currently have other priorities, but as soon 
  as I
  see an available slot of time, if no one beats me to it, I'll go into it in
  more detail.
 
 
 I was wondering whether there is anything I can do to make this move forward. 

Not much until we have reviewed the patch and provided comments. Then, if
modifications are needed you may want to do them yourself and provide an
updated patch, which would speed up its integration in the code base.

I've only had a quick look so far and can't give much feedback yet. I'll try to
have a deeper look in the next days. A few things I noticed, though:
- the IllegalArgumentException in ExtensionElementMapping will have to be
replaced by a call to FOP's event notification mechanism (so that the message
can be localized, among others things). Have a look in, e.g.,
org.apache.fop.fo.flow.Table.java to see how it is used (TableEventProducer in
that case)
- the new features will have to be documented on the website. The corresponding
source files may be found in the src/documentation/content/xdocs/trunk
directory. The ideal place probably is extensions.xml, with a link in
output.xml.
- there are Checkstyle warnings in the new code. You can set up Checkstyle
using the checkstyle-4.0.xml at the root of the project.

Those are things that we will have to do before applying the patch anyway, so
if you want to speed up the process you can have a go at them.

Back later, hopefully, for comments on the functionalities themselves.

Thanks!
Vincent

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: Hacking a temporary solution for Changing IPD

2009-06-18 Thread Andreas Delmelle 

On 18 Jun 2009, at 20:26, Simon Pepping wrote:

Hi Simon, Vincent,


snip /
I get the feeling that this means that you are planning to relaunch
line breaking while in the page breaking phase. Is that possible?


What I was wondering too, and why I somehow believe that suspending  
line-breaking and starting the page-breaking phase earlier is likely  
to be 'easier' to implement (even though the required changes would  
impact a lot more classes). It would basically come down to extending  
the approach that is currently taken when dealing with span-changes or  
forced page- or column-breaks: exit the line-breaking loop, start page- 
breaking for the element-list up to that point, and return later to  
continue with the line-breaking. Currently, this approach always uses  
separate PageBreakingAlgorithm instances, but I don't think it would  
be very hard to re-use the same PBA and append the new elements to its  
'current paragraph'.



Regards

Andreas