The best way to prove or falsify this theory would be to create a PDF
that uses the "cm" operator, but has different values for hy and hx, and
then render the image with PDFBox.
Or render PDF files and see what happens... I just changed that method,
and get several differences in the Basiswissen-Vorschriften.pdf file, on
page 1 (bottom left), page 6 (the two top right pictures). The file
eci_altona-test-suite-v2_technical_H.pdf looks weird now. Same for
example_013.pdf, which is about these things.
Tilman
Am 27.12.2014 um 14:16 schrieb John Hewson:
Hi All,
I’ve been looking at the Matrix class and trying to understand if it has some
problems. The Matrix class
in PDFBox uses the following matrix:
| sx hy 0 |
| hx sy 0 |
| tx ty 1 |
In a PDF file this matrix is represented as the 6-element array [a, b, c, d, e,
f] where the meaning of
the values comes from p118 and is [sx, hx, hy, sy, tx, ty]. Note that h is used
to mean shear/skew.
The Concatenate operator class populates the Matrix as follows:
PDFBox PDF Spec
newMatrix.setValue(0, 0, a.floatValue()); sx a = sx
newMatrix.setValue(0, 1, b.floatValue()); hy c = hx <- Flipped?
newMatrix.setValue(1, 0, c.floatValue()); hx b = hy <- Flipped?
newMatrix.setValue(1, 1, d.floatValue()); sy d = sy
newMatrix.setValue(2, 0, e.floatValue()); tx e = tx
newMatrix.setValue(2, 1, f.floatValue()); ty f = ty
I’ve annotated what PDFBox does on the left, compared to the PDF spec, the x
and y skew elements
(hx and hy) are flipped in PDFBox. This flip matches the order in which AWT’s
AffineTransform’s
constructor expects its elements but does not match the arrays used in the PDF
spec.
Are we accidentally flipping skew-x and skew-y in the Concatenate operator?
-- John
