[
https://issues.apache.org/jira/browse/PDFBOX-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981966#comment-13981966
]
Tilman Hausherr commented on PDFBOX-2047:
-----------------------------------------
After fixing the problem I had a new one: toRGB() calls getWhitepoint() and
getBlackPoint(). If these aren't set, it would result in two new COSArray
objects being created each time a pixel is converted. So I am using a caching
mechanism. And I fixed getInitialColor() which was doing the opposite of what
was needed. And I added tests to prevent this from breaking in the future. This
was done in rev 1590229 for the trunk.
I'd handle the (different) change for the 1.8 branch after the 1.8.5 release so
that I don't interfere with the release preparation work.
> read operations alter PDLab object
> ----------------------------------
>
> Key: PDFBOX-2047
> URL: https://issues.apache.org/jira/browse/PDFBOX-2047
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.8.4, 1.8.5, 2.0.0
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
>
> This is a follow-up to PDFBOX-2042 but for PDLab: "A read operation must not
> alter the pdf."
> The problem described PDFBOX-2042 happened because the constructor called
> loadICCProfile(), which called getRangeForComponent(c), which altered its own
> object with (broken) default values. PDLab has no such constructor so Jurajs
> test won't show any problem, but this different test will:
> {code}
> PDLab pdLab = new PDLab();
> COSArray cosArray = (COSArray) pdLab.getCOSObject();
> COSDictionary dict = (COSDictionary)cosArray.getObject(1);
> pdLab.getBlackPoint();
> pdLab.getWhitepoint();
> pdLab.getARange();
> pdLab.getBRange();
> assertEquals("read operations should not change the size of /Lab
> objects", 0, dict.size());
> dict.toString(); // rev 1571125 does stack overflow here in 2.0
> {code}
> removing the assert brings a stack overflow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
