Jenkins build is back to stable : PDFBox-Trunk-jdk9 » Apache Preflight #21

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-Trunk-jdk9 » Apache PDFBox examples #21

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-Trunk-jdk9 » Apache PDFBox tools #21

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-Trunk-jdk9 #21

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-Trunk-jdk9 » Apache PDFBox #21

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-trunk » Apache PDFBox examples #3528

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-trunk #3528

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-trunk » Apache PDFBox tools #3528

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-trunk » Apache Preflight #3528

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to stable : PDFBox-trunk » Apache PDFBox #3528

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk » Apache PDFBox #3527

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk #3527

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk » Apache PDFBox examples #3527

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk » Apache Preflight #3527

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk » Apache PDFBox tools #3527

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126234#comment-16126234
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805035 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805035 ]

PDFBOX-3897: 2nd attempt with compatible raster

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-Trunk-jdk9 » Apache PDFBox examples #20

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-Trunk-jdk9 » Apache PDFBox tools #20

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-Trunk-jdk9 » Apache Preflight #20

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-Trunk-jdk9 » Apache PDFBox #20

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-Trunk-jdk9 #20

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126143#comment-16126143
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805023 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805023 ]

PDFBOX-3897: rev 1763808 no longer works on jdk9, try different attempt

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126123#comment-16126123
 ] 

Tilman Hausherr commented on PDFBOX-3897:
-

With the changes, the rendering tests fail in the jdk9 build on Jenkins (but 
not here on windows). The change broke the voodoo we did in PDDocument, now 
this code
{code}
PDDeviceRGB.INSTANCE.toRGB(new float[]{1,1,1,1});
{code}
does nothing. Previously that line would possibly do initialization in 
PDDeviceRGB.

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3875) Bookmarks inactive after PDFMergerUtility

[Maruan Sahyoun (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126114#comment-16126114
 ] 

Maruan Sahyoun commented on PDFBOX-3875:


/Outlines is also broken unfortunately

> Bookmarks inactive after PDFMergerUtility
> -
>
> Key: PDFBOX-3875
> URL: https://issues.apache.org/jira/browse/PDFBOX-3875
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 2.0.7
>Reporter: Senthilvinayaham Murugan
> Attachments: 000314.pdf, 000334.pdf, 000337.pdf, 001124.pdf, 
> 001929.pdf, 001995.pdf, Acrobat_merge.pdf, EA-25471_frontmatter.pdf, 
> PDFsam_merge.pdf, W05.pdf
>
>
> I have two Bookmark PDFs with Page and Content links which works fine 
> independently. But when i use PDFMergerUtility, though it successfully merges 
> with PDF bookmarks, some of the page and content links are not working.
> Could you please let me know if you have any suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-Trunk-jdk9 » Apache PDFBox #19

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-Trunk-jdk9 » Apache PDFBox #19

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3875) Bookmarks inactive after PDFMergerUtility

[Senthilvinayaham Murugan (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125952#comment-16125952
 ] 

Senthilvinayaham Murugan commented on PDFBOX-3875:
--

[~tilman]:Thanks a bunch for alternate option, let me try this with PDFSAM.

> Bookmarks inactive after PDFMergerUtility
> -
>
> Key: PDFBOX-3875
> URL: https://issues.apache.org/jira/browse/PDFBOX-3875
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 2.0.7
>Reporter: Senthilvinayaham Murugan
> Attachments: 000314.pdf, 000334.pdf, 000337.pdf, 001124.pdf, 
> 001929.pdf, 001995.pdf, Acrobat_merge.pdf, EA-25471_frontmatter.pdf, 
> PDFsam_merge.pdf, W05.pdf
>
>
> I have two Bookmark PDFs with Page and Content links which works fine 
> independently. But when i use PDFMergerUtility, though it successfully merges 
> with PDF bookmarks, some of the page and content links are not working.
> Could you please let me know if you have any suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-Trunk-jdk9 #18

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-Trunk-jdk9 » Apache PDFBox #18

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3875) Bookmarks inactive after PDFMergerUtility

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125938#comment-16125938
 ] 

Tilman Hausherr commented on PDFBOX-3875:
-

You could use http://www.pdfsam.org/ which is a fork of PDFBox and does not 
have the bug.

> Bookmarks inactive after PDFMergerUtility
> -
>
> Key: PDFBOX-3875
> URL: https://issues.apache.org/jira/browse/PDFBOX-3875
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 2.0.7
>Reporter: Senthilvinayaham Murugan
> Attachments: 000314.pdf, 000334.pdf, 000337.pdf, 001124.pdf, 
> 001929.pdf, 001995.pdf, Acrobat_merge.pdf, EA-25471_frontmatter.pdf, 
> PDFsam_merge.pdf, W05.pdf
>
>
> I have two Bookmark PDFs with Page and Content links which works fine 
> independently. But when i use PDFMergerUtility, though it successfully merges 
> with PDF bookmarks, some of the page and content links are not working.
> Could you please let me know if you have any suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125920#comment-16125920
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805021 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1805021 ]

PDFBOX-3897: correct comment

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125919#comment-16125919
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805020 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805020 ]

PDFBOX-3897: correct comment

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125891#comment-16125891
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1805019 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805019 ]

PDFBOX-2852: remove unused import

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125885#comment-16125885
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1805018 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805018 ]

PDFBOX-2852: use jdk7 syntax

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125880#comment-16125880
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805016 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805016 ]

PDFBOX-3897: increase the threshhold for diff because such differences are 
invisible to the human eye

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125881#comment-16125881
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805017 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1805017 ]

PDFBOX-3897: increase the threshhold for diff because such differences are 
invisible to the human eye

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3875) Bookmarks inactive after PDFMergerUtility

[Senthilvinayaham Murugan (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125870#comment-16125870
 ] 

Senthilvinayaham Murugan commented on PDFBOX-3875:
--

Oh mighty volunteers, is there anybody to provide me a solutions who would not 
take another month?

> Bookmarks inactive after PDFMergerUtility
> -
>
> Key: PDFBOX-3875
> URL: https://issues.apache.org/jira/browse/PDFBOX-3875
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 2.0.7
>Reporter: Senthilvinayaham Murugan
> Attachments: 000314.pdf, 000334.pdf, 000337.pdf, 001124.pdf, 
> 001929.pdf, 001995.pdf, Acrobat_merge.pdf, EA-25471_frontmatter.pdf, 
> PDFsam_merge.pdf, W05.pdf
>
>
> I have two Bookmark PDFs with Page and Content links which works fine 
> independently. But when i use PDFMergerUtility, though it successfully merges 
> with PDF bookmarks, some of the page and content links are not working.
> Could you please let me know if you have any suggestions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125865#comment-16125865
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805014 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1805014 ]

PDFBOX-3897: avoid sRGB self-conversion

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3897) Avoid sRGB self-conversions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125866#comment-16125866
 ] 

ASF subversion and git services commented on PDFBOX-3897:
-

Commit 1805015 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1805015 ]

PDFBOX-3897: avoid sRGB self-conversion

> Avoid sRGB self-conversions
> ---
>
> Key: PDFBOX-3897
> URL: https://issues.apache.org/jira/browse/PDFBOX-3897
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Rendering
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
>  Labels: optimization
> Fix For: 2.0.8, 3.0.0
>
> Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf
>
>
> 1)
> PDICCBased.java detects if the colorspace is sRGB, but does not use this 
> advantage fully. {{toRGB()}} should return its argument when the colorspace 
> is sRGB.
> The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
> improvement can be experienced with files that use such pseudo ICC 
> colorspaces for shading, because there a large number of colors have to be 
> converted.
> 2)
> PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the 
> sRGB color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
> {{awtColorSpace.toRGB()}} instead of just returning its argument.
> This second change does not have much influence on the speed of rendering on 
> my old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
> complete rendering tests are now done in 300 instead of 400 seconds.
> Rendering regression tests show a lot of small differences. I assume that 
> differences of 1/255 in a color somehow propagate and worsen, e.g. through 
> transparency layers. I looked at a few, the differences are detected by the 
> rendering tests but are invisible to my eye (in the diff file, the difference 
> can be made visible by setting Gamma to minimum). I've therefore increased 
> the tolerance to 3 units to avoid the work of analyzing hundreds of file 
> differences. Those that remain are still invisible to my eye, except 
> PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
> Adobe before (the whole file is very broken and the first page logs over 3000 
> errors). I suspect it is an incorrect RGB value that isn't clipped anymore 
> now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-3897) Avoid sRGB self-conversions

[Tilman Hausherr (JIRA)]

Tilman Hausherr created PDFBOX-3897:
---

 Summary: Avoid sRGB self-conversions
 Key: PDFBOX-3897
 URL: https://issues.apache.org/jira/browse/PDFBOX-3897
 Project: PDFBox
  Issue Type: Improvement
  Components: Rendering
Affects Versions: 2.0.7
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 2.0.8, 3.0.0
 Attachments: PDFJS-6737-veryslow.pdf, PDFJS-8446-p1-slow.pdf

1)
PDICCBased.java detects if the colorspace is sRGB, but does not use this 
advantage fully. {{toRGB()}} should return its argument when the colorspace is 
sRGB.

The files from PDF.js issues 8446 and 6737 are much faster now. The speed 
improvement can be experienced with files that use such pseudo ICC colorspaces 
for shading, because there a large number of colors have to be converted.

2)
PDDeviceRGB.java also converts colors to itself. {{awtColorSpace}} is the sRGB 
color space and so is {{/DeviceRGB}}, yet {{toRGB()}} calls 
{{awtColorSpace.toRGB()}} instead of just returning its argument.

This second change does not have much influence on the speed of rendering on my 
old computer (4 cores). But on the new computer (8 cores, 16 threads) the 
complete rendering tests are now done in 300 instead of 400 seconds.

Rendering regression tests show a lot of small differences. I assume that 
differences of 1/255 in a color somehow propagate and worsen, e.g. through 
transparency layers. I looked at a few, the differences are detected by the 
rendering tests but are invisible to my eye (in the diff file, the difference 
can be made visible by setting Gamma to minimum). I've therefore increased the 
tolerance to 3 units to avoid the work of analyzing hundreds of file 
differences. Those that remain are still invisible to my eye, except 
PDFBOX-3693-656282-p1-p8.pdf, which is very different but was different than 
Adobe before (the whole file is very broken and the first page logs over 3000 
errors). I suspect it is an incorrect RGB value that isn't clipped anymore now.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-3896) UnsupportedOperationException

[Jorge Spinsanti (JIRA)]

Jorge Spinsanti created PDFBOX-3896:
---

 Summary: UnsupportedOperationException
 Key: PDFBOX-3896
 URL: https://issues.apache.org/jira/browse/PDFBOX-3896
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.6
Reporter: Jorge Spinsanti
 Attachments: UnsupportedOperationException.pdf

Stacktrace:
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)
at java.util.AbstractList.add(AbstractList.java:108)
at 
org.apache.pdfbox.pdfparser.COSParser.parseDictObjects(COSParser.java:611)
at 
org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:241)
at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:276)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1132)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1066)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:141)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-3895) IllegalBlockSizeException.pdf

[Jorge Spinsanti (JIRA)]

Jorge Spinsanti created PDFBOX-3895:
---

 Summary: IllegalBlockSizeException.pdf
 Key: PDFBOX-3895
 URL: https://issues.apache.org/jira/browse/PDFBOX-3895
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.6
Reporter: Jorge Spinsanti
 Attachments: IllegalBlockSizeException.pdf

I got the following stacktrace to get text from PDF:
{code}
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 
when decrypting with padded cipher
at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptDataAESother(SecurityHandler.java:292)
at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:153)
at 
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:454)
at 
org.apache.pdfbox.pdfparser.COSParser.parseFileObject(COSParser.java:785)
at 
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:742)
at 
org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:673)
at 
org.apache.pdfbox.pdfparser.COSParser.parseDictObjects(COSParser.java:633)
at 
org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:241)
at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:276)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1132)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1066)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:141)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3401) PDObjectReference getReferencedObject() returns null is referenced obj is not a COSStream

[Esteban Nicolas Ruiz (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125715#comment-16125715
 ] 

Esteban Nicolas Ruiz commented on PDFBOX-3401:
--

Hello. I'm facing the same issue.

I have tryied changing a local copy of pdfbox sources, line 165 in 
./pdfbox/src/main/java/org/apache/pdfbox/pdmodel/common/PDNumberTreeNode.java: 
{{COSObjectable pdValue = convertCOSToPD( cosValue );}}
for
{{COSObjectable pdValue = (COSObjectable)  cosValue ;}}

That solved the issue in my case (the node contained a reference, maybe it 
fails with an array of references?) 

> PDObjectReference getReferencedObject() returns null is referenced obj is not 
> a COSStream
> -
>
> Key: PDFBOX-3401
> URL: https://issues.apache.org/jira/browse/PDFBOX-3401
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 1.8.9, 2.0.2, 2.0.3, 3.0.0
>Reporter: Mark Melling
> Attachments: 000671.pdf
>
>
> When creating a pdf I am setting a PDAnnotation as the referenced object of a 
> PDObjectReference using setReferencedObject.
> When I subsequently load the same document and then call getReferencedObject 
> on the PDObjectReference, null is returned. This is because an exception is 
> thrown in PDXObject.createXObject (called inside getReferencedObject) as the 
> referenced object is not a COSStream, just a COSDictionary.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-3894) NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode

[Jorge Spinsanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jorge Spinsanti updated PDFBOX-3894:

Attachment: NPEonPDPageTree.pdf

> NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode
> --
>
> Key: PDFBOX-3894
> URL: https://issues.apache.org/jira/browse/PDFBOX-3894
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.6
>Reporter: Jorge Spinsanti
> Attachments: NPEonPDPageTree.pdf
>
>
> I got a NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode. 
> Stacktrace:
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode(PDPageTree.java:307)
>   at org.apache.pdfbox.pdmodel.PDPageTree.access$100(PDPageTree.java:38)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:164)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:169)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:159)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:153)
>   at org.apache.pdfbox.pdmodel.PDPageTree.iterator(PDPageTree.java:123)
>   at 
> org.apache.pdfbox.text.PDFTextStripper.processPages(PDFTextStripper.java:314)
>   at 
> org.apache.pdfbox.text.PDFTextStripper.writeText(PDFTextStripper.java:266)
>   at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:117)
>   at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:159)
>   at 
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
>   ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-3894) NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode

[Jorge Spinsanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jorge Spinsanti updated PDFBOX-3894:

Component/s: PDModel

> NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode
> --
>
> Key: PDFBOX-3894
> URL: https://issues.apache.org/jira/browse/PDFBOX-3894
> Project: PDFBox
>  Issue Type: Bug
>  Components: PDModel
>Affects Versions: 2.0.6
>Reporter: Jorge Spinsanti
> Attachments: NPEonPDPageTree.pdf
>
>
> I got a NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode. 
> Stacktrace:
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode(PDPageTree.java:307)
>   at org.apache.pdfbox.pdmodel.PDPageTree.access$100(PDPageTree.java:38)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:164)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:169)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:159)
>   at 
> org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:153)
>   at org.apache.pdfbox.pdmodel.PDPageTree.iterator(PDPageTree.java:123)
>   at 
> org.apache.pdfbox.text.PDFTextStripper.processPages(PDFTextStripper.java:314)
>   at 
> org.apache.pdfbox.text.PDFTextStripper.writeText(PDFTextStripper.java:266)
>   at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:117)
>   at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:159)
>   at 
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
>   ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-3894) NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode

[Jorge Spinsanti (JIRA)]

Jorge Spinsanti created PDFBOX-3894:
---

 Summary: NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode
 Key: PDFBOX-3894
 URL: https://issues.apache.org/jira/browse/PDFBOX-3894
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.6
Reporter: Jorge Spinsanti


I got a NPE on org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode. Stacktrace:
{code}
java.lang.NullPointerException
at 
org.apache.pdfbox.pdmodel.PDPageTree.isPageTreeNode(PDPageTree.java:307)
at org.apache.pdfbox.pdmodel.PDPageTree.access$100(PDPageTree.java:38)
at 
org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:164)
at 
org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.enqueueKids(PDPageTree.java:169)
at 
org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:159)
at 
org.apache.pdfbox.pdmodel.PDPageTree$PageIterator.(PDPageTree.java:153)
at org.apache.pdfbox.pdmodel.PDPageTree.iterator(PDPageTree.java:123)
at 
org.apache.pdfbox.text.PDFTextStripper.processPages(PDFTextStripper.java:314)
at 
org.apache.pdfbox.text.PDFTextStripper.writeText(PDFTextStripper.java:266)
at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:117)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:159)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
...
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-3893) encryption webpage doesnt compile

[simon steiner (JIRA)]

simon steiner created PDFBOX-3893:
-

 Summary: encryption webpage doesnt compile
 Key: PDFBOX-3893
 URL: https://issues.apache.org/jira/browse/PDFBOX-3893
 Project: PDFBox
  Issue Type: Bug
  Components: Documentation
Reporter: simon steiner


Change:
PDDocument doc = PDDocument.load("filename.pdf");
to:
PDDocument doc = PDDocument.load(new File("filename.pdf"));

https://pdfbox.apache.org/2.0/cookbook/encryption.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: PDFBox and PDF 2.0

[Andreas Lehmkühler]

> Maruan Sahyoun  hat am 11. August 2017 um 18:36 
> geschrieben:
> 
> 
> 
> > Am 11.08.2017 um 18:24 schrieb Tilman Hausherr :
> > 
> > Am 11.08.2017 um 10:07 schrieb Maruan Sahyoun:
> >> Hi,
> >> 
> >> with PDF 2.0 being available it might be time to start to introduce some 
> >> of the features in PDFBox (no rush I think as it will need some time to be 
> >> adopted). One feature I would like to discuss if it would be good to 
> >> introduce a version support so one could say to save as PDF 2.0 file or 
> >> some other version. E.g. one could now use utf-8 encoded text strings 
> >> which will introduce issues in readers not supporting that where some of 
> >> the other changes like new properties will simply be ignored.
> > 
We need to support such 2.0 features as there will be some people who will use 
PDFBox to render such pdfs. And if we add that utf-8 support for reading it 
shouldn't be that hard to add it for writing as well.
I like Maruans idea to add some version support. So that adding some features 
to a pdf could change the version automatically or could trigger an exception.

Andreas

> > We can indicate the version when saving, and we know the version when 
> > loading... Maybe what you mean is to propagate the version to the COS 
> > classes?
> 
> Yes - as there are some areas in PDF 2.0 - such as utf-8 encoded text strings 
> - which we would need to enable e.g. when generating a document from scratch 
> or adding new annotations. Currently if we pass text as an input to some of 
> our setters when writing out the file it will not use utf-8 text strings 
> which is fine as it will ensure that older readers are able to read the 
> content. But if you'd like to 'enforce' 2.0 there is currently now way in 
> doing so.
> 
> For other areas where there is a new 'PDF Object' or property with 2.0 we can 
> wait until there is demand for it and let the developer decide if that shall 
> be used (the same way we handle it today as there is no specific version 
> support in PDFBox i.e. one could declare the file as being 1.4. compliant but 
> use 1.7 features wthout any complaints). The low level lib we are I think 
> that's acceptable.
> 
> Maruan
> 
> > 
> > Tilman
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> > For additional commands, e-mail: dev-h...@pdfbox.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org