Surprisingly, this didn't help. (The reason is that one of the
constructors fixes the wrong order)
What did help was making a code change:
protected AffineTransform calculateAffineTransform(PDPage page,
PDRectangle overlayMediaBox)
{
AffineTransform at = new AffineTransform();
PDRectangle pageMediaBox = page.getMediaBox();
float hShift = pageMediaBox.getLowerLeftX() +
(pageMediaBox.getWidth() - overlayMediaBox.getWidth()) / 2.0f;
float vShift = pageMediaBox.getLowerLeftY() +
(pageMediaBox.getHeight() - overlayMediaBox.getHeight()) / 2.0f;
at.translate(hShift, vShift);
return at;
}
the change is in the calculation of hShift and vShift. The problem is
that the coordinate origin isn't at (0,0) but that (0, -6600).
Alternatively, change the overlay PDF so that it has a similar origin.
You will have to make a change anyway because that watermark is too small.
I think I shouldn't make a change in PDFBox 2 / 3 because it could break
existing applications where overlays work but the mediabox is not (0,0)
but close to. So this change should be done only for the trunk.
Tilman
Am 05.08.2025 um 07:20 schrieb Marc Kaufman:
Rectangles need to be normalized for use:
Rectangles are used to describe locations on a page and bounding
boxes for a variety of objects, such as fonts. A rectangle is
written as an array of four numbers giving the coordinates of a
pair of diagonally opposite corners. Typically, the array takes
the form
[ llx lly urx ury ]
specifying the lower-left x, lower-left y, upper-right x, and
upper-right ycoordinates of the rectangle, in that order. The
other two corners of the rectangle are then assumed to have
coordinates (llx, ury) and (urx, lly).
/Note: Although rectangles are conventionally specified by their
lower-left and upper-right corners, it is acceptable to specify
any two diagonally opposite corners. Applications that process PDF
should be prepared to normalize such rectangles in situations
where specific corners are required./
So the MediaBox should be (rewritten internally) as (0, -6600, 5100, 0)
I've seen this fairly often in a previous life.
Marc
On 8/4/2025 8:56 PM, Tilman Hausherr wrote:
Hi,
I'm not yet sure if this is a bug or expected behavior, but I noticed
this:
The mediabox (and the cropbox) have a negative Y bound, this is
weird. It could be that the software sets the overlay at (0,0) so it
will be invisible.
Tilman
Am 05.08.2025 um 00:04 schrieb Brent:
I have a sample pdf and overlay attached. When I run the command:
java.exe -jar pdfbox-app-3.0.5.jar overlay -i originalPDF.pdf
-default overlay.pdf -position FOREGROUND -o output.pdf
The resulting PDF does not have an overlay. The document size
increases, so I believe the overlay operation is performed, but it
does not render. Note, the same result occurs when running the API.
I have used overlay successfully on other documents, but I have a
document set that it does not work on and this is a sample of the
scenario.
Is this something that should be reported as a bug?
Thank you,
Brent
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail:users-h...@pdfbox.apache.org
