You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2014/12/10 21:27:12 UTC
[jira] [Comment Edited] (PDFBOX-1094) Pattern colorspace support
[ https://issues.apache.org/jira/browse/PDFBOX-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241673#comment-14241673 ]
John Hewson edited comment on PDFBOX-1094 at 12/10/14 8:26 PM:
---------------------------------------------------------------
I'm not satisfied with my workaround in PDTilingPattern.getMatrix() either, so any ideas are more than welcome.
The matrices you mention from the textbook (section 5.2) are not the same as those used in PDF. In PDF the matrices in are 3x3 and have an implicit last column of (0, 1, 0), these are the same as those in section 5.4 of the textbook "Homogeneous coordinates". So the rotation matrix is actually:
{code}
// This column is implicit, it's always (0, 0, 1)
// |
// v
[ cos(rot) −sin(rot) 0 ]
[ sin(rot) cos(rot) 0 ]
[ 0 0 1 ] // < this row is [ tx ty 0 ] where tx = ty = 0 for rotation
{code}
You'll find the same matrix on p120 of PDF 32000 but with elements labelled from _a_.._f_ and the rotation formula on p118. Because the last column is implicit, matrices in PDF are given as arrays with only six elements, but they are treated as 3x3 matrices, with 9 elements, as above.
The problematic matrix in PoolCompPDFA.pdf is given as the array \[0 15.7 -15.7 0 792 0\], which corresponds to the following matrix, I've annotated its interpretation too:
{code}
[ 0 15.7 0 ] [ sx hx 0 ]
[ -15.7 0 0 ] = [ hy sx 0 ] Where s$ = scale, t$ = translate, h$ = shear
[ 792 0 1 ] [ tx ty 1 ] for $ = (x, y).
{code}
Note that sx and sy are both zero, while the workaround is pure guesswork, the problem itself ("invalid matrices", "scaling factor of zero") isn't based on any assumptions, the scaling factors _are_ zero. Any matrix with a scaling factor of zero is broken from a PDF standpoint as it is not invertible and will always result in all transformed points being (0,0). The PDF spec doesn't forbid such matrices, but it notes that they are usually "unintended" and specifically cites scaling by zero as a likely problem:
{quote}
Such noninvertible transformations are not very useful and generally arise from unintended operations, such as scaling by 0. Use of a noninvertible matrix when painting graphics objects can result in unpredictable behaviour.
(PDF 32000, p120-121, "Note 3")
{quote}
With regards to my workaround, for the problematic matrix mentioned, it works as follows:
{code}
// Bad array giving matrix with scaling of zero
[0 15.7 -15.7 0 792 0] = [sx hx hy sy tx ty] // According to the PDF spec.
-> [hx 0 hy 0 tx ty] // Workaround interpretes like this.
-> [hx sx hy sy tx ty] // Though we could do this.
{code}
The problem is that the shear and scale elements are the wrong way around in the matrix. I tried setting a scale of 1 and the results were not correct, it seems that no skew was intended by the original author, only a scale. This aspect of the fix is pure guesswork, I don't understand how the user made this mistake or why Acrobat and other viewers are apparently correcting it.
was (Author: jahewson):
I'm not satisfied with my workaround in PDTilingPattern.getMatrix() either, so any ideas are more than welcome.
The matrices you mention from the textbook (section 5.2) are not the same as those used in PDF. In PDF the matrices in are 3x3 and have an implicit last column of (0, 1, 0), these are the same as those in section 5.4 of the textbook "Homogeneous coordinates". So the rotation matrix is actually:
{code}
// This column is implicit, it's always (0, 0, 1)
// |
// v
[ cos(rot) −sin(rot) 0 ]
[ sin(rot) cos(rot) 0 ]
[ 0 0 1 ] // < this row is [ tx ty 0 ] where tx = ty = 0 for rotation
{code}
You'll find the same matrix on p120 of PDF 32000 but with elements labelled from _a_.._f_ and the rotation formula on p118. Because the last column is implicit, matrices in PDF are given as arrays with only six elements, but they are treated as 3x3 matrices, with 9 elements, as above.
The problematic matrix in PoolCompPDFA.pdf is given as the array \[0 15.7 -15.7 0 792 0\], which corresponds to the following matrix, I've annotated its interpretation too:
{code}
[ 0 15.7 0 ] [ sx hx 0 ]
[ -15.7 0 0 ] = [ hy sx 0 ] Where s$ = scale, t$ = translate, h$ = shear
[ 792 0 1 ] [ tx ty 1 ] for $ = (x, y).
{code}
Note that sx and sy are both zero, while the workaround is pure guesswork, the problem itself ("invalid matrices", "scaling factor of zero") isn't based on any assumptions, the scaling factors _are_ zero. Any matrix with a scaling factor of zero is broken from a PDF standpoint as it is not invertible and will always result in all transformed points being (0,0). The PDF spec doesn't forbid such matrices, but it notes that they are usually "unintended" and specifically cites scaling by zero as a likely problem:
{quote}
Such noninvertible transformations are not very useful and generally arise from unintended operations, such as scaling by 0. Use of a noninvertible matrix when painting graphics objects can result in unpredictable behaviour.
(PDF 32000, p120-121, "Note 3")
{quote}
With regards to my workaround, for the problematic matrix mentioned, it works as follows:
{code}
// Bad array giving matrix with scaling of zero
[0 15.7 -15.7 0 792 0] = [sx hx hy sy tx ty] // According to the PDF spec.
-> [hx 0 hy 0 tx ty] // Workaround interpretes like this.
-> [hx sx hy sy tx ty] // Though we could interpret it like this.
{code}
The problem is that the shear and scale elements are the wrong way around in the matrix. I tried setting a scale of 1 and the results were not correct, it seems that no skew was intended by the original author, only a scale. This aspect of the fix is pure guesswork, I don't understand how the user made this mistake or why Acrobat and other viewers are apparently correcting it.
> Pattern colorspace support
> --------------------------
>
> Key: PDFBOX-1094
> URL: https://issues.apache.org/jira/browse/PDFBOX-1094
> Project: PDFBox
> Issue Type: Improvement
> Components: Rendering
> Affects Versions: 1.6.0, 2.0.0
> Reporter: Andreas Lehmkühler
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: ColoredTilingPaint.patch, PATTYP1.pdf, PATTYP2.pdf, PDF32000_2008_pg737.pdf, PDFBOX-1094-065514-XStep32767.pdf, PDFBOX-1094-094730.pdf, PDFBOX-1094-096213-p18.pdf, PDFBOX-1094-118358-Step-32767.pdf, PDFBOX-1094-PDFBOX-269.pdf, PDFBOX-1094-tiling_pattern.pdf-1-broken-tiles-with-ceil.png, PDFBOX-1861-tracemonkey13.png, PDFStreamEngine.patch, PageDrawer.patch, _pdfbox-1094-tiling_pattern.pdf-1-blurry.png, bugzilla8677511.jpg, gs-bugzilla688728.pdf, gs-bugzilla691715.pdf, gs-bugzilla692152.pdf, gs-bugzilla692503.ai, gs-bugzilla693653.pdf, gs-bugzilla694385.pdf, jagpdf_doc_patterns.pdf, jagpdf_doc_patterns.pdf-1.png, pdfbox-1094-pdf32000_2008_pg737.pdf-1.png, pdfbox-1094-pdf32000_2008_pg737.pdf-1.png, pdfbox-1094-pdfbox-269.pdf-2.png, pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1861-tracemonkey.pdf-13.png, pdfbox-1861-tracemonkey.pdf-13.png, tiling_pattern.pdf, v2_tiling_patterns_v2.patch
>
>
> PDFBox doesn't support PDPattern colorspaces
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)