[jira] [Comment Edited] (PDFBOX-2047) read operations alter PDLab object

["Tilman Hausherr (JIRA)" <ji...@apache.org>]

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

Tilman Hausherr edited comment on PDFBOX-2047 at 4/26/14 1:14 PM:
------------------------------------------------------------------

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 and 1590235 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.


was (Author: tilman):
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)