https://issues.apache.org/bugzilla/show_bug.cgi?id=47311--- Comment #44 from Jeremias Maerki <
jeremias@...> 2009-11-25 12:01:00 UTC ---
(In reply to comment #43)
> Hi All,
>
> We have found one issue during testing this new feature.
> The issue lies in PageBoundaries.java in calculating crop/bleed boxes.
>
> The offsets order is: [top, right, bottom, left], so to calculate Y size of
> the final box we should use the 'bottom' instead of 'top' offset :
>
>
> return new Rectangle(originalRect.x - coords[3],
> - originalRect.y - coords[0],
> + originalRect.y - coords[2],
> originalRect.width + coords[3] + coords[1],
> originalRect.height + coords[0] + coords[2]);
>
>
>
> Please find in the attachments the fix patch. (Comment#41)
> Also I have attached the full patch for FOP-0.95 version (Comment#42) if
> somebody will have a need to use this feature with previous version.
I've taken a look at that. Thanks for spotting the problem, Boris, but your
solution was not the right one. But you brought me on the right track. I've
just found out what our mistake is: PDF specifies the boxes as "rectangles"
which are defined as "llx lly urx ury" (i.e. lower left to upper right). But
our/FOP's Rectangle2D objects are actually "upper left to lower right". In
PageBoundaries we're still in FOP's coordinate system which starts at the upper
left. So we have to calculate the right values for the default PDF coordinate
system. Boris' change would have broken a test case and created a bug on the
bitmap production side. So the right change is to do a transformation from
FOP's internal coordinate system to PDF's default one in PDFDocumentHandler:
http://svn.apache.org/viewvc?rev=884241&view=revBoris, can you please verify that this fix also work for you? Thanks!
--
Configure bugmail:
https://issues.apache.org/bugzilla/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
