[jira] [Created] (PDFBOX-2047) read operations alter PDLab object
Tilman Hausherr created PDFBOX-2047:
---
Summary: 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)
Re: New PDFBox bugfix release 1.8.5
Hi Maruan, [1] everything works. Thanks! Looks like we are done here and I'm going to cut the release on Monday or Tuesday evening (UTC+2) BR Andreas Lehmkühler [1] https://builds.apache.org/job/PDFBox%201.8.x/122/ Am 26.04.2014 00:07, schrieb Maruan Sahyoun: Hi Andreas, I’ve committed the changes. Fingers crossed that I did that correctly this time. BR Maruan Am 24.04.2014 um 11:52 schrieb Andreas Lehmkühler andr...@lehmi.de: Hi, I'm planning to cut the release at the beginning of the next week. Any objections? @Maruan What about your pending javadoc changes? Do you need more time or help? As we are not in a hurry, it wouldn't be a problem to postpone the release process for another week or two. BR Andreas Lehmkühler Andreas Lehmkuehler andr...@lehmi.de hat am 18. April 2014 um 15:36 geschrieben: Hi, it's time to cut a new bugfix release as there are a lot of fixes in our queue. Additionally I already announced a possible new release in the second quarter and people are already asking for it. ;-) WDYT? Is there anything we should wait for? Any fix only available in the trunk which should be merged into then branch as well? What about the 4 open issues [1] marked with fix for 1.8.5? BR Andreas Lehmkühler [1] http://s.apache.org/VwQ
Re: New PDFBox bugfix release 1.8.5
Yes, already monitored it :-) thanks for the patience. BR Maruan Am 26.04.2014 um 10:29 schrieb Andreas Lehmkuehler andr...@lehmi.de: Hi Maruan, [1] everything works. Thanks! Looks like we are done here and I'm going to cut the release on Monday or Tuesday evening (UTC+2) BR Andreas Lehmkühler [1] https://builds.apache.org/job/PDFBox%201.8.x/122/ Am 26.04.2014 00:07, schrieb Maruan Sahyoun: Hi Andreas, I’ve committed the changes. Fingers crossed that I did that correctly this time. BR Maruan Am 24.04.2014 um 11:52 schrieb Andreas Lehmkühler andr...@lehmi.de: Hi, I'm planning to cut the release at the beginning of the next week. Any objections? @Maruan What about your pending javadoc changes? Do you need more time or help? As we are not in a hurry, it wouldn't be a problem to postpone the release process for another week or two. BR Andreas Lehmkühler Andreas Lehmkuehler andr...@lehmi.de hat am 18. April 2014 um 15:36 geschrieben: Hi, it's time to cut a new bugfix release as there are a lot of fixes in our queue. Additionally I already announced a possible new release in the second quarter and people are already asking for it. ;-) WDYT? Is there anything we should wait for? Any fix only available in the trunk which should be merged into then branch as well? What about the 4 open issues [1] marked with fix for 1.8.5? BR Andreas Lehmkühler [1] http://s.apache.org/VwQ
[jira] [Commented] (PDFBOX-2047) read operations alter PDLab object
[
https://issues.apache.org/jira/browse/PDFBOX-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (PDFBOX-2047) read operations alter PDLab object
[
https://issues.apache.org/jira/browse/PDFBOX-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (PDFBOX-2046) [PATCH] Can't read the embedded Type1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982079#comment-13982079 ] Tilman Hausherr commented on PDFBOX-2046: - You're not a man many words, obviously. Can you attach the PDF file or is it confidential? Alternatively, can you extract the type1 font stream and attach it? [PATCH] Can't read the embedded Type1 font -- Key: PDFBOX-2046 URL: https://issues.apache.org/jira/browse/PDFBOX-2046 Project: PDFBox Issue Type: Bug Reporter: simon steiner Labels: type1, type1font Attachments: type1parser.patch java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage x.pdf SEVERE: Can't read the embedded Type1 font java.io.IOException: Found Token[kind=NAME, text=end] but expected LITERAL SEVERE: Can't read the embedded Type1 font java.io.IOException: Found Token[kind=NAME, text=currentdict] but expected LITERAL -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-2046) [PATCH] Can't read the embedded Type1 font
[ https://issues.apache.org/jira/browse/PDFBOX-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982079#comment-13982079 ] Tilman Hausherr edited comment on PDFBOX-2046 at 4/26/14 7:25 PM: -- You're not a man of many words, obviously. Can you attach the PDF file or is it confidential? Alternatively, can you extract the type1 font stream and attach it? was (Author: tilman): You're not a man many words, obviously. Can you attach the PDF file or is it confidential? Alternatively, can you extract the type1 font stream and attach it? [PATCH] Can't read the embedded Type1 font -- Key: PDFBOX-2046 URL: https://issues.apache.org/jira/browse/PDFBOX-2046 Project: PDFBox Issue Type: Bug Reporter: simon steiner Labels: type1, type1font Attachments: type1parser.patch java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar PDFToImage x.pdf SEVERE: Can't read the embedded Type1 font java.io.IOException: Found Token[kind=NAME, text=end] but expected LITERAL SEVERE: Can't read the embedded Type1 font java.io.IOException: Found Token[kind=NAME, text=currentdict] but expected LITERAL -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (PDFBOX-2042) ColorSpace with empty Range array
[ https://issues.apache.org/jira/browse/PDFBOX-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980403#comment-13980403 ] Tilman Hausherr edited comment on PDFBOX-2042 at 4/26/14 9:52 PM: -- Thanks for the feedback. Btw, PDLab has the same problem, see PDFBOX-2047. was (Author: tilman): Thanks for the feedback. Btw, PDLab has the same problem, I'll create an issue soon. ColorSpace with empty Range array - Key: PDFBOX-2042 URL: https://issues.apache.org/jira/browse/PDFBOX-2042 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.4, 1.8.5, 2.0.0 Reporter: Juraj Lonc Assignee: Tilman Hausherr Fix For: 1.8.5, 2.0.0 Attachments: ModifyTest.java, pdfbox18.pdf, pdfbox20.pdf I have PDF document where I am modifying PDPage content stream. Saved document is invalid (Adobe reader complains about it). I have narrowed it down to ColorSpace. Original document has colorspace: /ColorSpace /Cs6 [/ICCBased /Alternate /DeviceRGB /Filter /FlateDecode /Length 2597 /N 3 ] Modified document has colorspace: /ColorSpace /Cs6 [/ICCBased /Alternate /DeviceRGB /Filter /FlateDecode /Length 2597 /N 3 /Range [] ] When I manually remove /Range [] from PDF then Adobe reader opens it without an error. Obviously that range is added by calling PDICCBased.getRangeArray(0) somewhere. -- This message was sent by Atlassian JIRA (v6.2#6252)
