date:20140811

2014-08-11 Thread ASF subversion and git services (JIRA)


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

Tilman Hausherr updated PDFBOX-2267:


Attachment: PDFBOX-2265-igalia.pdf

 IOException and partial rendering and colorspace creation error
 ---

 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0

 Attachments: PDFBOX-2265-igalia.pdf


 I get this exception with the attached PDF, and the upper arc of the image is 
 not rendered:
 {code}
 java.io.IOException: Unknown colorspace 
 type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
 COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
 COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
 (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
 COSFloat{0.824905}]}) }
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
 {code}
 There are several causes: (1) in PDICCBased.createColorSpace() the variable 
 numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
 fixed in the 2.0 version but not in the 1.8 version. Because the exception 
 isn't caught correctly, the alternate color space is to be used. (3) The 
 implementation of getAlternateColorSpaces() (that part existed before it 
 became an apache project) thinks that this is an array of colorspaces.This
 {code}
 [/Lab/BlackPoint[0.0 0.0 0.0]/Range[-128.0 127.0 -128.0 
 127.0]/WhitePoint[0.964203 1.0 0.824905]]
 {code}
 is considered an array of two colorspaces. This is contrary to the spec, 
 which mentions An alternate colour space. I will fix the bug without 
 changing the API in 1.8, but will change the API in 2.0, which will be
 {code}
 public PDColorSpace getAlternateColorSpace() throws IOException
 {code}
 instead of
 {code}
 public ListPDColorSpace getAlternateColorSpaces() throws IOException
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

2014-08-11 Thread Andreas Lehmkuehler


Hi,


Am 11.08.2014 18:35, schrieb John Hewson:

Andreas,

What I had been thinking was that now that 2.0 is getting closer that me wight 
want to do less with 1.8, but I agree with you that we don’t need any fixed 
rules, staying flexible is better. It sounds like we might want to think about 
some guidelines for 1.8 after 2.0 is released to avoid a “Windows XP” 
situation, but we’re not at that point yet.

Yes, good point. Hopefully 1.8.7 will be the last 1.8 release before 2.0 :-)


Cheers

-- John


BR
Andreas Lehmkühler



On 11 Aug 2014, at 03:57, Andreas Lehmkühler andr...@lehmi.de wrote:


Hi,


John Hewson j...@jahewson.com hat am 7. August 2014 um 18:48 geschrieben:


Perhaps we should stop adding new features to 1.8, and only fix the most
problematic bugs?

We never were that strict about the contents of a bugfix release in the past.
We always added some improvements or new features. Most of them were small
and/or hadn't a huge impact on the code/functionality. Some were added
because people were eagerly waiting for them. There aren't any rules what
to add or not and IMHO we don't need any.


BR
Andreas Lehmkühler



-- John


On 7 Aug 2014, at 09:11, Tilman Hausherr thaush...@t-online.de wrote:

+1

but after I've ported the GSoC2014-improved shading package to 1.8

Tilman

Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:

Hi,

there is already a number of solved issues and I guess it's
time for a new bugfix release.

I'm working on PDFBOX-2250 and I'd like to finish that
first but how about a new release in 2 or 3 weeks from now?

WDYT?

BR
Andreas Lehmkühler

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error


[ 
https://issues.apache.org/jira/browse/PDFBOX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092980#comment-14092980
 ] 

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

Commit 1617326 from [~tilman] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1617326 ]

PDFBOX-2267: use getter instead of uninitalized variable; rethrow unhandled 
exception; treat /Alternate as ONE colorspace

 IOException and partial rendering and colorspace creation error
 ---

 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0

 Attachments: PDFBOX-2265-igalia.pdf


 I get this exception with the attached PDF, and the upper arc of the image is 
 not rendered:
 {code}
 java.io.IOException: Unknown colorspace 
 type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
 COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
 COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
 (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
 COSFloat{0.824905}]}) }
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
 {code}
 There are several causes: (1) in PDICCBased.createColorSpace() the variable 
 numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
 fixed in the 2.0 version but not in the 1.8 version. Because the exception 
 isn't caught correctly, the alternate color space is to be used. (3) The 
 implementation of getAlternateColorSpaces() (that part existed before it 
 became an apache project) thinks that this is an array of colorspaces.This
 {code}
 [/Lab/BlackPoint[0.0 0.0 0.0]/Range[-128.0 127.0 -128.0 
 127.0]/WhitePoint[0.964203 1.0 0.824905]]
 {code}
 is considered an array of two colorspaces. This is contrary to the spec, 
 which mentions An alternate colour space. I will fix the bug without 
 changing the API in 1.8, but will change the API in 2.0, which will be
 {code}
 public PDColorSpace getAlternateColorSpace() throws IOException
 {code}
 instead of
 {code}
 public ListPDColorSpace getAlternateColorSpaces() throws IOException
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2268) AES-256 decryptions fails

Michele Balistreri created PDFBOX-2268:
--

 Summary: AES-256 decryptions fails
 Key: PDFBOX-2268
 URL: https://issues.apache.org/jira/browse/PDFBOX-2268
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri


When opening a document encrypted with AES-256 (owner password only) by 
providing no password, the isUserPasswordMethod fails, since it tries to 
decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately 
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms 
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead 
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but 
I am completely new to the project and have not yet had the time to study all 
coding conventions. Considering the patch is very small maybe someone can take 
it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails


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

Michele Balistreri updated PDFBOX-2268:
---

Attachment: AES256-fix.diff

Patch for issue PDFBOX-2268

 AES-256 decryptions fails
 -

 Key: PDFBOX-2268
 URL: https://issues.apache.org/jira/browse/PDFBOX-2268
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri
 Attachments: AES256-fix.diff


 When opening a document encrypted with AES-256 (owner password only) by 
 providing no password, the isUserPasswordMethod fails, since it tries to 
 decrypt a null pointer.
 Also, the code validating the Perms dictionary is correct, but unfortunately 
 not even Acrobat seems to write Perms correctly (in my case P = F0C0 and 
 Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue 
 instead of throwing an exception would be more adequate.
 Provided is a patch for both issues. I understand it is probably suboptimal 
 but I am completely new to the project and have not yet had the time to study 
 all coding conventions. Considering the patch is very small maybe someone can 
 take it as a pointer of what needs to be changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails

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

Michele Balistreri updated PDFBOX-2268:
---

Description:
When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPassword method fails, since it tries
(indirectly) to decrypt a null pointer.

Also, the code validating the Perms dictionary is correct, but unfortunately
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and Perms
= F2C0), so that check needs to be relaxed. Perhaps logging the issue instead
of throwing an exception would be more adequate.

Provided is a patch for both issues. I understand it is probably suboptimal but
I am completely new to the project and have not yet had the time to study all
coding conventions. Considering the patch is very small maybe someone can take
it as a pointer of what needs to be changes.

was:
When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPasswordMethod fails, since it tries to
decrypt a null pointer.

AES-256 decryptions fails
-

Key: PDFBOX-2268
URL: https://issues.apache.org/jira/browse/PDFBOX-2268
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri
Attachments: AES256-fix.diff

When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPassword method fails, since it tries
(indirectly) to decrypt a null pointer.
Also, the code validating the Perms dictionary is correct, but unfortunately
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and
Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue
instead of throwing an exception would be more adequate.
Provided is a patch for both issues. I understand it is probably suboptimal
but I am completely new to the project and have not yet had the time to study
all coding conventions. Considering the patch is very small maybe someone can
take it as a pointer of what needs to be changes.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2268) AES-256 decryptions fails

2014-08-11 Thread ASF subversion and git services (JIRA)

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

Michele Balistreri updated PDFBOX-2268:
---

Description:
When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPassword method fails, since it tries,
indirectly, to decrypt a null pointer by calling computeUserPassword. The
result of computeUserPassword would be ignored even if the call succeeded,
since it is not need for AES-256 encryption.

was:
When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPassword method fails, since it tries
(indirectly) to decrypt a null pointer.

AES-256 decryptions fails
-

When opening a document encrypted with AES-256 (owner password only) by
providing no password, the isUserPassword method fails, since it tries,
indirectly, to decrypt a null pointer by calling computeUserPassword. The
result of computeUserPassword would be ignored even if the call succeeded,
since it is not need for AES-256 encryption.
Also, the code validating the Perms dictionary is correct, but unfortunately
not even Acrobat seems to write Perms correctly (in my case P = F0C0 and
Perms = F2C0), so that check needs to be relaxed. Perhaps logging the issue
instead of throwing an exception would be more adequate.
Provided is a patch for both issues. I understand it is probably suboptimal
but I am completely new to the project and have not yet had the time to study
all coding conventions. Considering the patch is very small maybe someone can
take it as a pointer of what needs to be changes.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: PDFBox 1.8.7 release?

2014-08-11 Thread Maruan Sahyoun


Am 11.08.2014 um 18:59 schrieb Andreas Lehmkuehler andr...@lehmi.de:

 Hi,
 
 
 Am 11.08.2014 18:35, schrieb John Hewson:
 Andreas,
 
 What I had been thinking was that now that 2.0 is getting closer that me 
 wight want to do less with 1.8, but I agree with you that we don’t need any 
 fixed rules, staying flexible is better. It sounds like we might want to 
 think about some guidelines for 1.8 after 2.0 is released to avoid a 
 “Windows XP” situation, but we’re not at that point yet.
 Yes, good point. Hopefully 1.8.7 will be the last 1.8 release before 2.0 :-)
 

As 2.0 breaks the current API (which is intended) I suspect that there will be 
bugfixes for 1.8 needed for some time.

 Cheers
 
 -- John
 
 BR
 Andreas Lehmkühler
 
 
 On 11 Aug 2014, at 03:57, Andreas Lehmkühler andr...@lehmi.de wrote:
 
 Hi,
 
 John Hewson j...@jahewson.com hat am 7. August 2014 um 18:48 geschrieben:
 
 
 Perhaps we should stop adding new features to 1.8, and only fix the most
 problematic bugs?
 We never were that strict about the contents of a bugfix release in the 
 past.
 We always added some improvements or new features. Most of them were small
 and/or hadn't a huge impact on the code/functionality. Some were added
 because people were eagerly waiting for them. There aren't any rules what
 to add or not and IMHO we don't need any.
 
 
 BR
 Andreas Lehmkühler
 
 
 -- John
 
 On 7 Aug 2014, at 09:11, Tilman Hausherr thaush...@t-online.de wrote:
 
 +1
 
 but after I've ported the GSoC2014-improved shading package to 1.8
 
 Tilman
 
 Am 07.08.2014 12:35, schrieb Andreas Lehmkühler:
 Hi,
 
 there is already a number of solved issues and I guess it's
 time for a new bugfix release.
 
 I'm working on PDFBOX-2250 and I'd like to finish that
 first but how about a new release in 2 or 3 weeks from now?
 
 WDYT?
 
 BR
 Andreas Lehmkühler

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error


[ 
https://issues.apache.org/jira/browse/PDFBOX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093005#comment-14093005
 ] 

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

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

PDFBOX-2267: treat /Alternate as ONE colorspace

 IOException and partial rendering and colorspace creation error
 ---

 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0

 Attachments: PDFBOX-2265-igalia.pdf


 I get this exception with the attached PDF, and the upper arc of the image is 
 not rendered:
 {code}
 java.io.IOException: Unknown colorspace 
 type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
 COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
 COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
 (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
 COSFloat{0.824905}]}) }
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
 {code}
 There are several causes: (1) in PDICCBased.createColorSpace() the variable 
 numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
 fixed in the 2.0 version but not in the 1.8 version. Because the exception 
 isn't caught correctly, the alternate color space is to be used. (3) The 
 implementation of getAlternateColorSpaces() (that part existed before it 
 became an apache project) thinks that this is an array of colorspaces.This
 {code}
 [/Lab/BlackPoint[0.0 0.0 0.0]/Range[-128.0 127.0 -128.0 
 127.0]/WhitePoint[0.964203 1.0 0.824905]]
 {code}
 is considered an array of two colorspaces. This is contrary to the spec, 
 which mentions An alternate colour space. I will fix the bug without 
 changing the API in 1.8, but will change the API in 2.0, which will be
 {code}
 public PDColorSpace getAlternateColorSpace() throws IOException
 {code}
 instead of
 {code}
 public ListPDColorSpace getAlternateColorSpaces() throws IOException
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2267) IOException and partial rendering and colorspace creation error

2014-08-11 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093008#comment-14093008
 ] 

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

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

PDFBOX-2267: treat /Alternate as ONE colorspace

 IOException and partial rendering and colorspace creation error
 ---

 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0

 Attachments: PDFBOX-2265-igalia.pdf


 I get this exception with the attached PDF, and the upper arc of the image is 
 not rendered:
 {code}
 java.io.IOException: Unknown colorspace 
 type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
 COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
 COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
 (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
 COSFloat{0.824905}]}) }
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
 {code}
 There are several causes: (1) in PDICCBased.createColorSpace() the variable 
 numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
 fixed in the 2.0 version but not in the 1.8 version. Because the exception 
 isn't caught correctly, the alternate color space is to be used. (3) The 
 implementation of getAlternateColorSpaces() (that part existed before it 
 became an apache project) thinks that this is an array of colorspaces.This
 {code}
 [/Lab/BlackPoint[0.0 0.0 0.0]/Range[-128.0 127.0 -128.0 
 127.0]/WhitePoint[0.964203 1.0 0.824905]]
 {code}
 is considered an array of two colorspaces. This is contrary to the spec, 
 which mentions An alternate colour space. I will fix the bug without 
 changing the API in 1.8, but will change the API in 2.0, which will be
 {code}
 public PDColorSpace getAlternateColorSpace() throws IOException
 {code}
 instead of
 {code}
 public ListPDColorSpace getAlternateColorSpaces() throws IOException
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2265) ArrayIndexOutOfBoundsException in PDICCBased.loadICCProfile


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

Tilman Hausherr updated PDFBOX-2265:


Description: 
I get this exception with the attached file:
{code}
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.init(PDICCBased.java:84)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.init(PDDeviceN.java:87)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
{code}

The cause is this line:
{code}
float[] initial = new float[getColorSpaceType()];
{code}
replacing it with this line that makes more sense
{code}
float[] initial = new float[getNumberOfComponents()];
{code}
gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
hit in the IDE in the popup. 

The file now renders without exception. There's a different exception in 1.8, 
see PDFBOX-2267.

  was:
I get this exception with the attached file:
{code}
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.init(PDICCBased.java:84)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.init(PDDeviceN.java:87)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
at 
org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
at 
org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
{code}

The cause is this line:
{code}
float[] initial = new float[getColorSpaceType()];
{code}
replacing it with this line that makes more sense
{code}
float[] initial = new float[getNumberOfComponents()];
{code}
gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
hit in the IDE in the popup. 

The file now renders without exception. There's a different exception in 1.8, 
I'll recheck the file after all the shading changes (including several 
bugfixes) have been implemented there.


 ArrayIndexOutOfBoundsException in PDICCBased.loadICCProfile
 ---

 Key: PDFBOX-2265
 URL: https://issues.apache.org/jira/browse/PDFBOX-2265
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 2.0.0

 Attachments: igalia-header-proof.pdf


 I get this exception with the attached file:
 {code}
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 1
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.loadICCProfile(PDICCBased.java:116)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.init(PDICCBased.java:84)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:135)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.init(PDDeviceN.java:87)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:123)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.create(PDColorSpace.java:55)
   at 
 org.apache.pdfbox.pdmodel.graphics.shading.PDShading.getColorSpace(PDShading.java:212)
 {code}
 The cause is this line:
 {code}
 float[] initial = new float[getColorSpaceType()];
 {code}
 replacing it with this line that makes more sense
 {code}
 float[] initial = new float[getNumberOfComponents()];
 {code}
 gets rid of the exception. I assume that this is a typo, i.e. wrong line was 
 hit in the IDE in the popup. 
 The file now renders without exception. There's a different exception in 1.8, 
 see PDFBOX-2267.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (PDFBOX-2267) IOException and partial rendering and colorspace creation error


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

Tilman Hausherr resolved PDFBOX-2267.
-

Resolution: Fixed

 IOException and partial rendering and colorspace creation error
 ---

 Key: PDFBOX-2267
 URL: https://issues.apache.org/jira/browse/PDFBOX-2267
 Project: PDFBox
  Issue Type: Bug
  Components: Parsing, Rendering
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 1.8.7, 2.0.0

 Attachments: PDFBOX-2265-igalia.pdf


 I get this exception with the attached PDF, and the upper arc of the image is 
 not rendered:
 {code}
 java.io.IOException: Unknown colorspace 
 type:COSDictionary{(COSName{BlackPoint}:COSArray{[COSFloat{0.0}, 
 COSFloat{0.0}, COSFloat{0.0}]}) (COSName{Range}:COSArray{[COSFloat{-128.0}, 
 COSFloat{127.0}, COSFloat{-128.0}, COSFloat{127.0}]}) 
 (COSName{WhitePoint}:COSArray{[COSFloat{0.964203}, COSFloat{1.0}, 
 COSFloat{0.824905}]}) }
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:159)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:78)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpaceFactory.createColorSpace(PDColorSpaceFactory.java:62)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.getAlternateColorSpaces(PDICCBased.java:291)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDICCBased.createColorSpace(PDICCBased.java:154)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDDeviceN.createColorSpace(PDDeviceN.java:124)
   at 
 org.apache.pdfbox.pdmodel.graphics.color.PDColorSpace.getJavaColorSpace(PDColorSpace.java:85)
 {code}
 There are several causes: (1) in PDICCBased.createColorSpace() the variable 
 numberOfComponents is -1; (2) the exception is not caught correctly. Both are 
 fixed in the 2.0 version but not in the 1.8 version. Because the exception 
 isn't caught correctly, the alternate color space is to be used. (3) The 
 implementation of getAlternateColorSpaces() (that part existed before it 
 became an apache project) thinks that this is an array of colorspaces.This
 {code}
 [/Lab/BlackPoint[0.0 0.0 0.0]/Range[-128.0 127.0 -128.0 
 127.0]/WhitePoint[0.964203 1.0 0.824905]]
 {code}
 is considered an array of two colorspaces. This is contrary to the spec, 
 which mentions An alternate colour space. I will fix the bug without 
 changing the API in 1.8, but will change the API in 2.0, which will be
 {code}
 public PDColorSpace getAlternateColorSpace() throws IOException
 {code}
 instead of
 {code}
 public ListPDColorSpace getAlternateColorSpaces() throws IOException
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2201) getKeywords returns null although keywords are present


[ 
https://issues.apache.org/jira/browse/PDFBOX-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093064#comment-14093064
 ] 

Tilman Hausherr commented on PDFBOX-2201:
-

No problem this time, your issue showed that the sample code had to be improved 
:-)

 getKeywords returns null although keywords are present
 --

 Key: PDFBOX-2201
 URL: https://issues.apache.org/jira/browse/PDFBOX-2201
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
 Environment: Win64
Reporter: Walter Kehl
Priority: Minor
 Fix For: 1.8.7, 2.0.0

 Attachments: Roland_Berger_TAB_Industry_4_0.pdf


 When accessing a PDF document which clearly has keywords in its meta data , 
 the function call 
 PDDocumentInformation documentInfo = document.getDocumentInformation();
 String info = documentInfo.getKeywords();
 returns null. 
 Sample PDF is attached. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2201) getKeywords returns null although keywords are present

2014-08-11 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093066#comment-14093066
 ] 

Tilman Hausherr commented on PDFBOX-2201:
-

I see that there's a comment by PDF Architect [~leonardr] which appeared in the 
dev list but not here, so I add it for the completeness of the record:
{quote}
There is nothing magic about how Acrobat/Reader goes from XMP to DocInfo
(and vice-versa).  It is documented in our own specs (the XMP specs,as you
point to) as well as being standardized in the PDF/A and PDF/X standards
from ISO.
{quote}

 getKeywords returns null although keywords are present
 --

 Key: PDFBOX-2201
 URL: https://issues.apache.org/jira/browse/PDFBOX-2201
 Project: PDFBox
  Issue Type: Bug
  Components: PDModel
Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
 Environment: Win64
Reporter: Walter Kehl
Priority: Minor
 Fix For: 1.8.7, 2.0.0

 Attachments: Roland_Berger_TAB_Industry_4_0.pdf


 When accessing a PDF document which clearly has keywords in its meta data , 
 the function call 
 PDDocumentInformation documentInfo = document.getDocumentInformation();
 String info = documentInfo.getKeywords();
 returns null. 
 Sample PDF is attached. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093086#comment-14093086
 ] 

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

Commit 1617339 from [~lehmi] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1617339 ]

PDFBOX-2250: parse an optional cross-reference stream to get object numbers for 
compressed objects as well

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved.
 I'm planing to solve at least some of them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

2014-08-11 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093088#comment-14093088
 ] 

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

Commit 1617340 from [~lehmi] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1617340 ]

PDFBOX-2250: parse an optional cross-reference stream to get object numbers for 
compressed objects as well

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved.
 I'm planing to solve at least some of them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093106#comment-14093106
 ] 

Andreas Lehmkühler commented on PDFBOX-2250:


In contrast to the old parser the non-sequential one didn't parse 
cross-reference streams. I've added that feature so that especially object 
references for compressed objects could be found now.

This should improve the parser once more if it comes to pdfs using object 
streams. I've used this [sample 
pdf|http://bewerbung.fh-kaernten.at/fileadmin/Anleitung-PDF-erstellen.pdf]  
provided by Martin Tappler on dev@pdfboxf

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism

2014-08-11 Thread Thomas Chojecki (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093152#comment-14093152
]

Thomas Chojecki commented on PDFBOX-2250:
-

[~lehmi]
All fixes and improvements are targeting the non-sequential parser and I won't
port those changes to the old parser.

The old parser already has this feature or similar one as I remember. This was
needed as fix for a third party lib that creates documents that have a miss
matched offset by 2 or 3 bytes. You can find it in the PDFParser class line 923
(resolveConflicts).
https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdfparser/PDFParser.java#L923

I don't have read the whole coversation, but you wrote something of 200 bytes
self healing range. This can cause problems with pdfs that are broken and
include pdf documents as file attachment. The flatdecode algorithm sometimes
does not compress each block, so it will leave some plaintext pdf blocks whick
can contain parts like endstream or endobj. In this case it can happen that
the self healing algorithm runs into such an uncompressed block and fail
reading the object.

I hope you understand what I mean :-)

PS: some offtopic things. I think the signature implementation only work with
the old parser. So maybe someone can post this info on the website if the
default parser implementation change.

Improve XRef self healing mechanism
---

Key: PDFBOX-2250
URL: https://issues.apache.org/jira/browse/PDFBOX-2250
Project: PDFBox
Issue Type: Improvement
Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef
offsets. But that one was just a starter and there remain a lot of issues to
be solved. I'm planing to solve at least some of them.
All fixes and improvements are targeting the non-sequential parser and I
won't port those changes to the old parser.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)


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

Michele Balistreri updated PDFBOX-2269:
---

Description: 
This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2268

  was:
This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2286


 Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 -

 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff


 This patch adds support for decrypting files using the (deprecated) AES-256 
 scheme revision 5. The current version only support revision 6. Since 
 revision 5 files are generated by Acrobat 9, there is a relatively large 
 amount of them in the wild so support is needed.
 This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)

Michele Balistreri created PDFBOX-2269:
--

 Summary: Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff

This patch adds support for decrypting files using the (deprecated) AES-256 
scheme revision 5. The current version only support revision 6. Since revision 
5 files are generated by Acrobat 9, there is a relatively large amount of them 
in the wild so support is needed.

This patch includes also the fixes from PDFBOX-2286



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)


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

Michele Balistreri updated PDFBOX-2269:
---

Attachment: AES-256_Rev5.diff

 Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 -

 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff


 This patch adds support for decrypting files using the (deprecated) AES-256 
 scheme revision 5. The current version only support revision 6. Since 
 revision 5 files are generated by Acrobat 9, there is a relatively large 
 amount of them in the wild so support is needed.
 This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)


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

Michele Balistreri updated PDFBOX-2269:
---

Component/s: PDModel

 Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 -

 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
  Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff


 This patch adds support for decrypting files using the (deprecated) AES-256 
 scheme revision 5. The current version only support revision 6. Since 
 revision 5 files are generated by Acrobat 9, there is a relatively large 
 amount of them in the wild so support is needed.
 This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2269) Support for AES-256 Rev. 5 Decryption (Acrobat 9)


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

Michele Balistreri updated PDFBOX-2269:
---

Affects Version/s: 2.0.0

 Support for AES-256 Rev. 5 Decryption (Acrobat 9)
 -

 Key: PDFBOX-2269
 URL: https://issues.apache.org/jira/browse/PDFBOX-2269
 Project: PDFBox
  Issue Type: Improvement
  Components: PDModel
Affects Versions: 2.0.0
Reporter: Michele Balistreri
 Attachments: AES-256_Rev5.diff


 This patch adds support for decrypting files using the (deprecated) AES-256 
 scheme revision 5. The current version only support revision 6. Since 
 revision 5 files are generated by Acrobat 9, there is a relatively large 
 amount of them in the wild so support is needed.
 This patch includes also the fixes from PDFBOX-2268



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093186#comment-14093186
 ] 

Tilman Hausherr commented on PDFBOX-2250:
-

How/where can I see the difference between before and after for the sample PDF? 
Should the rendering be different, or something else?

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093187#comment-14093187
 ] 

Andreas Lehmkühler commented on PDFBOX-2250:


[~tilman] I should have be more specific. Use PDFDebugger and have a look at 
the root node. There isn't any StructTreeRoot when using the non sequential 
parser without my changes

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093191#comment-14093191
 ] 

Andreas Lehmkühler commented on PDFBOX-2250:


[~tchojecki] I'm aware of that feature. But that was more a brute force 
search. The non sequential parser is following the spec a relies on the 
xref-table itself. This issues targets some of the known problems such as wrong 
offsets. The bugfix/improvement for compress objects was just a sideproduct as 
I stumbeld upon that missing part.

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093197#comment-14093197
 ] 

Tilman Hausherr commented on PDFBOX-2250:
-

These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 (Missing root object specification in trailer)
- PDFBOX-1756 (Catalog cannot be found)
- PDFBOX-2251 (Missing root object specification in trailer)
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) Missing root object 
specification in trailer



 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093197#comment-14093197
 ] 

Tilman Hausherr edited comment on PDFBOX-2250 at 8/11/14 7:51 PM:
--

These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 (Missing root object specification in trailer)
- PDFBOX-1756 (Catalog cannot be found)
- PDFBOX-2251 (Missing root object specification in trailer)
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) Missing root object 
specification in trailer
- test-landscape2.pdf (Missing root object specification in trailer)



was (Author: tilman):
These files can no longer be opened with the nonsequential parser:
- PDFBOX-1577 (Missing root object specification in trailer)
- PDFBOX-1756 (Catalog cannot be found)
- PDFBOX-2251 (Missing root object specification in trailer)
- PDFBOX-1512 (immo-kurier_arsenal_93x62.pdf) Missing root object 
specification in trailer



 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism


[ 
https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093248#comment-14093248
 ] 

Andreas Lehmkühler commented on PDFBOX-2250:


Thanks for the fast feedback, I'll have a look

 Improve XRef self healing mechanism
 ---

 Key: PDFBOX-2250
 URL: https://issues.apache.org/jira/browse/PDFBOX-2250
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 1.8.6, 1.8.7, 2.0.0
Reporter: Andreas Lehmkühler
Assignee: Andreas Lehmkühler

 PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef 
 offsets. But that one was just a starter and there remain a lot of issues to 
 be solved. I'm planing to solve at least some of them.
 All fixes and improvements are targeting the non-sequential parser and I 
 won't port those changes to the old parser.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files


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

Tilman Hausherr updated PDFBOX-2261:


Attachment: screenshot-pdfdebugger.png

Here's a screenshot, that shows what I have to do to see the first few fields.

 Extremely long hang during getFields() on a few PDF files
 -

 Key: PDFBOX-2261
 URL: https://issues.apache.org/jira/browse/PDFBOX-2261
 Project: PDFBox
  Issue Type: Bug
  Components: AcroForm
Affects Versions: 1.8.6
Reporter: Tim Allison
Priority: Minor
 Attachments: 966679.pdf, screenshot-pdfdebugger.png


 When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
 during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files

2014-08-11 Thread Maruan Sahyoun (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093275#comment-14093275
 ] 

Maruan Sahyoun commented on PDFBOX-2261:


This looks quite complex for what should be plain form fields, although it’s 
valid. I can look into it later this week if no one else wants to before.

 Extremely long hang during getFields() on a few PDF files
 -

 Key: PDFBOX-2261
 URL: https://issues.apache.org/jira/browse/PDFBOX-2261
 Project: PDFBox
  Issue Type: Bug
  Components: AcroForm
Affects Versions: 1.8.6
Reporter: Tim Allison
Priority: Minor
 Attachments: 966679.pdf, screenshot-pdfdebugger.png


 When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
 during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2249) Listbox controls render incorrectly

2014-08-11 Thread Maruan Sahyoun (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093283#comment-14093283
]

Maruan Sahyoun commented on PDFBOX-2249:

I’ve fixed the list box appearance stream generation for the sample PDF in my
working copy. The result looks similar to what Adobe Acrobat displays.

I have a very limited number of AcroForms for testing so if someone could point
me to and/or provide additional sample forms that would be great. The fix is
for 1.8 only at that point in time as it’s duplicating a lot of code and
addresses the listbox only.

Listbox controls render incorrectly
---

Key: PDFBOX-2249
URL: https://issues.apache.org/jira/browse/PDFBOX-2249
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.6
Environment: Windows 7
Reporter: John McDonald
Assignee: Maruan Sahyoun
Labels: Appearance
Fix For: 1.8.7

Attachments: JMACTest.pdf, JMAC_PDFBOX_out.pdf, PDFBoxUtil.java,
PDFFormFields.pdf

I have a form with a listbox. I update the value in the listbox using the
following code:
PDChoiceField c = (PDChoiceField)f;
((PDChoiceField)f).setValue(2);
I have a combo box that uses the same choices, and it works fine. The issue
has to do with the rendering of the field. The update of the value (i.e.
setValue method) works fine, but when I look at the resulting output PDF the
choices have become unreadable because the font has gone way large.
I have searched the mailing list, and posted a question regarding this that
no one has answered, so I am now assuming this is an unknown bug.
Thanks

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files


[ 
https://issues.apache.org/jira/browse/PDFBOX-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093286#comment-14093286
 ] 

Tilman Hausherr commented on PDFBOX-2261:
-

Yes please do. What I did last week was to run in debug mode, then pressed 
pause. I saw about 20 identical recursive calls. I didn't test whether it runs 
forever or not.

 Extremely long hang during getFields() on a few PDF files
 -

 Key: PDFBOX-2261
 URL: https://issues.apache.org/jira/browse/PDFBOX-2261
 Project: PDFBox
  Issue Type: Bug
  Components: AcroForm
Affects Versions: 1.8.6
Reporter: Tim Allison
Priority: Minor
 Attachments: 966679.pdf, screenshot-pdfdebugger.png


 When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang 
 during acroForm.getFields().  This is a heavy load hang.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-2249) Listbox controls render incorrectly