Re: [VOTE] Release Apache PDFBox 1.8.2
Hi, I had a short test with pdfbox-app. Worked as expected. +1 Best regards, Timo Am 29.05.2013 20:32, schrieb Andreas Lehmkuehler: Hi, a candidate for the PDFBox 1.8.2 release is available at: http://people.apache.org/~lehmi/pdfbox/1.8.2/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. Please vote on releasing this package as Apache PDFBox 1.8.2. The vote is open for the next 72 hours and passes if a majority of at least three +1 PDFBox PMC votes are cast. [ ] +1 Release this package as Apache PDFBox 1.8.2 [ ] -1 Do not release this package because... Hers is my +1 BR Andreas Lehmkühler -- Timo Boehme OntoChem GmbH H.-Damerow-Str. 4 06120 Halle/Saale T: +49 345 4780474 F: +49 345 4780471 timo.boe...@ontochem.com _ OntoChem GmbH Geschäftsführer: Dr. Lutz Weber Sitz: Halle / Saale Registergericht: Stendal Registernummer: HRB 215461 _
Re: [VOTE] Release Apache PDFBox 1.8.2
+1 - thanks Andreas for reacting so quickly and having all the burden. BR Maruan Am 29.05.2013 um 20:32 schrieb Andreas Lehmkuehler : > Hi, > > a candidate for the PDFBox 1.8.2 release is available at: > >http://people.apache.org/~lehmi/pdfbox/1.8.2/ > > The release candidate is a zip archive of the sources in: > >http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ > > The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. > > Please vote on releasing this package as Apache PDFBox 1.8.2. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 PDFBox PMC votes are cast. > >[ ] +1 Release this package as Apache PDFBox 1.8.2 >[ ] -1 Do not release this package because... > > > Hers is my +1 > > BR > Andreas Lehmkühler
[VOTE] Release Apache PDFBox 1.8.2
Hi, a candidate for the PDFBox 1.8.2 release is available at: http://people.apache.org/~lehmi/pdfbox/1.8.2/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. Please vote on releasing this package as Apache PDFBox 1.8.2. The vote is open for the next 72 hours and passes if a majority of at least three +1 PDFBox PMC votes are cast. [ ] +1 Release this package as Apache PDFBox 1.8.2 [ ] -1 Do not release this package because... Hers is my +1 BR Andreas Lehmkühler
[jira] [Commented] (PDFBOX-1617) Null pointer exception
[ https://issues.apache.org/jira/browse/PDFBOX-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669540#comment-13669540 ] William Fausser commented on PDFBOX-1617: - Jasper is Not a PDF/A file by any means. I was expecting Preflight to still process > Null pointer exception > -- > > Key: PDFBOX-1617 > URL: https://issues.apache.org/jira/browse/PDFBOX-1617 > Project: PDFBox > Issue Type: Bug > Components: Preflight >Affects Versions: 1.8.1 > Environment: Red Hat Linux >Reporter: William Fausser > Attachments: jasper.pdf > > > jasper.pdf :: Exception in thread "main" java.lang.NullPointerException > at > org.apache.pdfbox.preflight.font.container.Type1Container.getFontProgramWidth(Type1Container.java:73) > at > org.apache.pdfbox.preflight.font.container.FontContainer.checkGlyphWith(FontContainer.java:115) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validText(ContentStreamWrapper.java:372) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validStringDefinition(ContentStreamWrapper.java:264) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.checkShowTextOperators(ContentStreamWrapper.java:203) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.processOperator(ContentStreamWrapper.java:180) > at > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) > at > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) > at > org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validPageContentStream(ContentStreamWrapper.java:75) > at > org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validateContent(SinglePageValidationProcess.java:174) > at > org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validate(SinglePageValidationProcess.java:83) > at > org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) > at > org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:49) > at > org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validatePage(PageTreeValidationProcess.java:56) > at > org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validate(PageTreeValidationProcess.java:45) > at > org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) > at > org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:88) > at > org.apache.pdfbox.preflight.PreflightDocument.validate(PreflightDocument.java:168) > at > org.apache.pdfbox.preflight.Validator_A1b.runSimple(Validator_A1b.java:158) > at > org.apache.pdfbox.preflight.Validator_A1b.main(Validator_A1b.java:125) > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1617) Null pointer exception
[ https://issues.apache.org/jira/browse/PDFBOX-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Fausser updated PDFBOX-1617: Attachment: jasper.pdf > Null pointer exception > -- > > Key: PDFBOX-1617 > URL: https://issues.apache.org/jira/browse/PDFBOX-1617 > Project: PDFBox > Issue Type: Bug > Components: Preflight >Affects Versions: 1.8.1 > Environment: Red Hat Linux >Reporter: William Fausser > Attachments: jasper.pdf > > > jasper.pdf :: Exception in thread "main" java.lang.NullPointerException > at > org.apache.pdfbox.preflight.font.container.Type1Container.getFontProgramWidth(Type1Container.java:73) > at > org.apache.pdfbox.preflight.font.container.FontContainer.checkGlyphWith(FontContainer.java:115) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validText(ContentStreamWrapper.java:372) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validStringDefinition(ContentStreamWrapper.java:264) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.checkShowTextOperators(ContentStreamWrapper.java:203) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.processOperator(ContentStreamWrapper.java:180) > at > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) > at > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) > at > org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) > at > org.apache.pdfbox.preflight.content.ContentStreamWrapper.validPageContentStream(ContentStreamWrapper.java:75) > at > org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validateContent(SinglePageValidationProcess.java:174) > at > org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validate(SinglePageValidationProcess.java:83) > at > org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) > at > org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:49) > at > org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validatePage(PageTreeValidationProcess.java:56) > at > org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validate(PageTreeValidationProcess.java:45) > at > org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) > at > org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:88) > at > org.apache.pdfbox.preflight.PreflightDocument.validate(PreflightDocument.java:168) > at > org.apache.pdfbox.preflight.Validator_A1b.runSimple(Validator_A1b.java:158) > at > org.apache.pdfbox.preflight.Validator_A1b.main(Validator_A1b.java:125) > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1617) Null pointer exception
William Fausser created PDFBOX-1617: --- Summary: Null pointer exception Key: PDFBOX-1617 URL: https://issues.apache.org/jira/browse/PDFBOX-1617 Project: PDFBox Issue Type: Bug Components: Preflight Affects Versions: 1.8.1 Environment: Red Hat Linux Reporter: William Fausser jasper.pdf :: Exception in thread "main" java.lang.NullPointerException at org.apache.pdfbox.preflight.font.container.Type1Container.getFontProgramWidth(Type1Container.java:73) at org.apache.pdfbox.preflight.font.container.FontContainer.checkGlyphWith(FontContainer.java:115) at org.apache.pdfbox.preflight.content.ContentStreamWrapper.validText(ContentStreamWrapper.java:372) at org.apache.pdfbox.preflight.content.ContentStreamWrapper.validStringDefinition(ContentStreamWrapper.java:264) at org.apache.pdfbox.preflight.content.ContentStreamWrapper.checkShowTextOperators(ContentStreamWrapper.java:203) at org.apache.pdfbox.preflight.content.ContentStreamWrapper.processOperator(ContentStreamWrapper.java:180) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268) at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235) at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215) at org.apache.pdfbox.preflight.content.ContentStreamWrapper.validPageContentStream(ContentStreamWrapper.java:75) at org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validateContent(SinglePageValidationProcess.java:174) at org.apache.pdfbox.preflight.process.reflect.SinglePageValidationProcess.validate(SinglePageValidationProcess.java:83) at org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) at org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:49) at org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validatePage(PageTreeValidationProcess.java:56) at org.apache.pdfbox.preflight.process.PageTreeValidationProcess.validate(PageTreeValidationProcess.java:45) at org.apache.pdfbox.preflight.utils.ContextHelper.callValidation(ContextHelper.java:74) at org.apache.pdfbox.preflight.utils.ContextHelper.validateElement(ContextHelper.java:88) at org.apache.pdfbox.preflight.PreflightDocument.validate(PreflightDocument.java:168) at org.apache.pdfbox.preflight.Validator_A1b.runSimple(Validator_A1b.java:158) at org.apache.pdfbox.preflight.Validator_A1b.main(Validator_A1b.java:125) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669535#comment-13669535 ] James Green commented on PDFBOX-1615: - Thanks guys - likely to be raised as a blocker bug for us in our product meeting tomorrow morning so be good to report an imminent fix. > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor >Assignee: Andreas Lehmkühler > Fix For: 1.8.2 > > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1610) Corrupted result pdf when overlay one document with another one
[ https://issues.apache.org/jira/browse/PDFBOX-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-1610. Resolution: Fixed Fix Version/s: 1.8.2 PDFBOX-1615 solves this issue too. Set to resolved > Corrupted result pdf when overlay one document with another one > --- > > Key: PDFBOX-1610 > URL: https://issues.apache.org/jira/browse/PDFBOX-1610 > Project: PDFBox > Issue Type: Bug > Components: Utilities >Affects Versions: 1.6.0, 1.8.1 >Reporter: Paul Heinrich >Assignee: Maruan Sahyoun >Priority: Critical > Fix For: 1.8.2 > > Attachments: kitest3_2904_01.6710338.0.pdf, pag.pdf > > > When overlay one document with another one with > org.apache.pdfbox.Overlay > the result pdf is corrupted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-1615. Resolution: Fixed Fix Version/s: 1.8.2 Assignee: Andreas Lehmkühler I canceled the vote and will integrate the solution into 1.8.2 > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor >Assignee: Andreas Lehmkühler > Fix For: 1.8.2 > > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[CANCEL][VOTE] Release Apache PDFBox 1.8.2
Hi, I cancel this vote due to a regression which was introduced with 1.8.0 which leads to malformed pdfs when using indexed colorspaces. As we already found a solution for the issue I'd like to redo the release including the fix, see [1] for further information. I'm going to start the release process in a couple of minutes. I hope everybody agrees with my decision. :-) Am 27.05.2013 20:39, schrieb Andreas Lehmkuehler: Hi, a candidate for the PDFBox 1.8.2 release is available at: http://people.apache.org/~lehmi/pdfbox/1.8.2/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. Please vote on releasing this package as Apache PDFBox 1.8.2. The vote is open for the next 72 hours and passes if a majority of at least three +1 PDFBox PMC votes are cast. [ ] +1 Release this package as Apache PDFBox 1.8.2 [ ] -1 Do not release this package because... Hers is my +1 BR Andreas Lehmkühler BR Andreas Lehmkühler [1] https://issues.apache.org/jira/browse/PDFBOX-1615
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669486#comment-13669486 ] Maruan Sahyoun commented on PDFBOX-1615: I think that would be good to do as there are already reports of that behavior BR Maruan > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669466#comment-13669466 ] Andreas Lehmkühler commented on PDFBOX-1615: I found the problem and fixed it in revision 1487557. So, should we cancel the vote to integrate this one? > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669458#comment-13669458 ] Andreas Lehmkühler commented on PDFBOX-1615: PDFBOX-1437 introduced the regression. The written COSString uses UTF-16 instead of a simple hex string for the lookup table (see COSString#getString) > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669423#comment-13669423 ] Andreas Lehmkühler commented on PDFBOX-1615: I guess I found a first hint for a solution. The lookup table of the indexed colorspace is altered. I'm investigating ... > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache PDFBox 1.8.2
Hi, Am 29.05.2013 16:03, schrieb Maruan Sahyoun: OK - give the fact that it's not 1.8.2's fault :-) +1 for 1.8.2 Thanks for reconsidering :-) BR Maruan Sahyoun Am 29.05.2013 um 16:00 schrieb Andreas Lehmkühler : Hi, Maruan Sahyoun hat am 29. Mai 2013 um 15:32 geschrieben: -1 as the 1.8.x line introduced a regression in color handling which can be seen by PDFBOX-1615. In addition there is another report of the issue with an eMail on the users mailing list "Bad image colours using new overlay code". Both files work fine using 1.7.1. I don't know (yet) which change introduced that behavior. Hmm, that's odd. It's not 1.8.2 which introduces the issue but 1.8.0. So the current release candidate isn't responsible for that regression but fixes some other issues. So at least 1.8.2 is an improvement compared to 1.8.1 and it wouldn't make things worse. I'd like to ask you to reconsider your veto, so that we don't have to wait for fixing this issue. Furthermore for some personal reasons I won't be able to act as release manager for the next 3 weeks. The issue can be reproduced by loading and saving the file so it's not because of Splitter or Overlay. Code to reproduce PDDocument document = new PDDocument.load(testfile) document.save(…) document.close(); Opening the newly saved file in Adobe Reader the colors are no longer OK. Sounds like PDFBOX-1610, or is it something else? BR Maruan Sahyoun Am 27.05.2013 um 20:39 schrieb Andreas Lehmkuehler : Hi, a candidate for the PDFBox 1.8.2 release is available at: http://people.apache.org/~lehmi/pdfbox/1.8.2/ The release candidate is a zip archive of the sources in: http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. Please vote on releasing this package as Apache PDFBox 1.8.2. The vote is open for the next 72 hours and passes if a majority of at least three +1 PDFBox PMC votes are cast. [ ] +1 Release this package as Apache PDFBox 1.8.2 [ ] -1 Do not release this package because... Hers is my +1 BR Andreas Lehmkühler BR Andreas Lehmkühler BR Andreas Lehmkühler
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669325#comment-13669325 ] James Green commented on PDFBOX-1615: - Per mailing list post we are now tracking this as it affects both old and new Overlay tools. > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1616) NumberFormatException i CMapParser.parseNextToken()
[ https://issues.apache.org/jira/browse/PDFBOX-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669269#comment-13669269 ] Maruan Sahyoun commented on PDFBOX-1616: Hi Thomas, would you share some sample code with us to reproduce the issue? BR Maruan > NumberFormatException i CMapParser.parseNextToken() > --- > > Key: PDFBOX-1616 > URL: https://issues.apache.org/jira/browse/PDFBOX-1616 > Project: PDFBox > Issue Type: Bug > Components: FontBox >Affects Versions: 1.8.1 >Reporter: Thomas Fossum > > When using PDType1Font (any of the 14 fonts available), and adding text with > contentStream.drawString(), we get a NumberformatException for string with 9 > characters, ex. "123456789" or "abcdefghi" > Stacktrace: > Caused by: java.lang.NumberFormatException: For input string: "8900146484" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Integer.parseInt(Integer.java:495) > at java.lang.Integer.(Integer.java:677) > at > org.apache.fontbox.cmap.CMapParser.parseNextToken(CMapParser.java:541) > at org.apache.fontbox.cmap.CMapParser.parse(CMapParser.java:119) > at org.apache.pdfbox.pdmodel.font.PDFont.parseCmap(PDFont.java:603) > at > org.apache.pdfbox.pdmodel.font.PDSimpleFont.extractToUnicodeEncoding(PDSimpleFont.java:458) > at > org.apache.pdfbox.pdmodel.font.PDSimpleFont.determineEncoding(PDSimpleFont.java:426) > at org.apache.pdfbox.pdmodel.font.PDFont.(PDFont.java:194) > at > org.apache.pdfbox.pdmodel.font.PDSimpleFont.(PDSimpleFont.java:88) > at > org.apache.pdfbox.pdmodel.font.PDType0Font.(PDType0Font.java:65) > at > org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:108) > at > org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:203) > at org.apache.pdfbox.pdmodel.PDResources.addFont(PDResources.java:588) > at org.apache.pdfbox.pdmodel.PDResources.addFont(PDResources.java:574) > at > org.apache.pdfbox.pdmodel.edit.PDPageContentStream.setFont(PDPageContentStream.java:308) > Issue https://issues.apache.org/jira/browse/PDFBOX-1225 handles a similar > error: An attempt to Integer.parseString() is made with a value > > Integer.MAX_VALUE. > Line 541 in CMAPParser.java should probably use Long datatype. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache PDFBox 1.8.2
Hi, > Maruan Sahyoun hat am 29. Mai 2013 um 15:32 > geschrieben: > > > -1 as the 1.8.x line introduced a regression in color handling which can be > seen by PDFBOX-1615. In addition there is another report of the issue with an > eMail on the users mailing list "Bad image colours using new overlay code". > Both files work fine using 1.7.1. I don't know (yet) which change introduced > that behavior. Hmm, that's odd. It's not 1.8.2 which introduces the issue but 1.8.0. So the current release candidate isn't responsible for that regression but fixes some other issues. So at least 1.8.2 is an improvement compared to 1.8.1 and it wouldn't make things worse. I'd like to ask you to reconsider your veto, so that we don't have to wait for fixing this issue. Furthermore for some personal reasons I won't be able to act as release manager for the next 3 weeks. > The issue can be reproduced by loading and saving the file so it's not because > of Splitter or Overlay. > > Code to reproduce > > PDDocument document = new PDDocument.load(testfile) > document.save(…) > document.close(); > > Opening the newly saved file in Adobe Reader the colors are no longer OK. Sounds like PDFBOX-1610, or is it something else? > BR > Maruan Sahyoun > > Am 27.05.2013 um 20:39 schrieb Andreas Lehmkuehler : > > > Hi, > > > > a candidate for the PDFBox 1.8.2 release is available at: > > > >http://people.apache.org/~lehmi/pdfbox/1.8.2/ > > > > The release candidate is a zip archive of the sources in: > > > >http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ > > > > The SHA1 checksum of the archive is > > 672303f65d2574ebffa992f3723759f5b7af0c0d. > > > > Please vote on releasing this package as Apache PDFBox 1.8.2. > > The vote is open for the next 72 hours and passes if a majority of at > > least three +1 PDFBox PMC votes are cast. > > > >[ ] +1 Release this package as Apache PDFBox 1.8.2 > >[ ] -1 Do not release this package because... > > > > > > Hers is my +1 > > > > BR > > Andreas Lehmkühler BR Andreas Lehmkühler
Re: [VOTE] Release Apache PDFBox 1.8.2
OK - give the fact that it's not 1.8.2's fault :-) +1 for 1.8.2 BR Maruan Sahyoun Am 29.05.2013 um 16:00 schrieb Andreas Lehmkühler : > Hi, > >> Maruan Sahyoun hat am 29. Mai 2013 um 15:32 >> geschrieben: >> >> >> -1 as the 1.8.x line introduced a regression in color handling which can be >> seen by PDFBOX-1615. In addition there is another report of the issue with an >> eMail on the users mailing list "Bad image colours using new overlay code". >> Both files work fine using 1.7.1. I don't know (yet) which change introduced >> that behavior. > > Hmm, that's odd. It's not 1.8.2 which introduces the issue but 1.8.0. So the > current > release candidate isn't responsible for that regression but fixes some other > issues. > So at least 1.8.2 is an improvement compared to 1.8.1 and it wouldn't make > things worse. > > I'd like to ask you to reconsider your veto, so that we don't have to wait for > fixing this issue. > Furthermore for some personal reasons I won't be able to act as release > manager > for the next 3 weeks. > >> The issue can be reproduced by loading and saving the file so it's not >> because >> of Splitter or Overlay. >> >> Code to reproduce >> >> PDDocument document = new PDDocument.load(testfile) >> document.save(…) >> document.close(); >> >> Opening the newly saved file in Adobe Reader the colors are no longer OK. > Sounds like PDFBOX-1610, or is it something else? > >> BR >> Maruan Sahyoun >> >> Am 27.05.2013 um 20:39 schrieb Andreas Lehmkuehler : >> >>> Hi, >>> >>> a candidate for the PDFBox 1.8.2 release is available at: >>> >>> http://people.apache.org/~lehmi/pdfbox/1.8.2/ >>> >>> The release candidate is a zip archive of the sources in: >>> >>> http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ >>> >>> The SHA1 checksum of the archive is >>> 672303f65d2574ebffa992f3723759f5b7af0c0d. >>> >>> Please vote on releasing this package as Apache PDFBox 1.8.2. >>> The vote is open for the next 72 hours and passes if a majority of at >>> least three +1 PDFBox PMC votes are cast. >>> >>> [ ] +1 Release this package as Apache PDFBox 1.8.2 >>> [ ] -1 Do not release this package because... >>> >>> >>> Hers is my +1 >>> >>> BR >>> Andreas Lehmkühler > > > BR > Andreas Lehmkühler
Re: [VOTE] Release Apache PDFBox 1.8.2
-1 as the 1.8.x line introduced a regression in color handling which can be seen by PDFBOX-1615. In addition there is another report of the issue with an eMail on the users mailing list "Bad image colours using new overlay code". Both files work fine using 1.7.1. I don't know (yet) which change introduced that behavior. The issue can be reproduced by loading and saving the file so it's not because of Splitter or Overlay. Code to reproduce PDDocument document = new PDDocument.load(testfile) document.save(…) document.close(); Opening the newly saved file in Adobe Reader the colors are no longer OK. BR Maruan Sahyoun Am 27.05.2013 um 20:39 schrieb Andreas Lehmkuehler : > Hi, > > a candidate for the PDFBox 1.8.2 release is available at: > >http://people.apache.org/~lehmi/pdfbox/1.8.2/ > > The release candidate is a zip archive of the sources in: > >http://svn.apache.org/repos/asf/pdfbox/tags/1.8.2/ > > The SHA1 checksum of the archive is 672303f65d2574ebffa992f3723759f5b7af0c0d. > > Please vote on releasing this package as Apache PDFBox 1.8.2. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 PDFBox PMC votes are cast. > >[ ] +1 Release this package as Apache PDFBox 1.8.2 >[ ] -1 Do not release this package because... > > > Hers is my +1 > > BR > Andreas Lehmkühler
[jira] [Created] (PDFBOX-1616) NumberFormatException i CMapParser.parseNextToken()
Thomas Fossum created PDFBOX-1616: - Summary: NumberFormatException i CMapParser.parseNextToken() Key: PDFBOX-1616 URL: https://issues.apache.org/jira/browse/PDFBOX-1616 Project: PDFBox Issue Type: Bug Components: FontBox Affects Versions: 1.8.1 Reporter: Thomas Fossum When using PDType1Font (any of the 14 fonts available), and adding text with contentStream.drawString(), we get a NumberformatException for string with 9 characters, ex. "123456789" or "abcdefghi" Stacktrace: Caused by: java.lang.NumberFormatException: For input string: "8900146484" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:495) at java.lang.Integer.(Integer.java:677) at org.apache.fontbox.cmap.CMapParser.parseNextToken(CMapParser.java:541) at org.apache.fontbox.cmap.CMapParser.parse(CMapParser.java:119) at org.apache.pdfbox.pdmodel.font.PDFont.parseCmap(PDFont.java:603) at org.apache.pdfbox.pdmodel.font.PDSimpleFont.extractToUnicodeEncoding(PDSimpleFont.java:458) at org.apache.pdfbox.pdmodel.font.PDSimpleFont.determineEncoding(PDSimpleFont.java:426) at org.apache.pdfbox.pdmodel.font.PDFont.(PDFont.java:194) at org.apache.pdfbox.pdmodel.font.PDSimpleFont.(PDSimpleFont.java:88) at org.apache.pdfbox.pdmodel.font.PDType0Font.(PDType0Font.java:65) at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:108) at org.apache.pdfbox.pdmodel.PDResources.getFonts(PDResources.java:203) at org.apache.pdfbox.pdmodel.PDResources.addFont(PDResources.java:588) at org.apache.pdfbox.pdmodel.PDResources.addFont(PDResources.java:574) at org.apache.pdfbox.pdmodel.edit.PDPageContentStream.setFont(PDPageContentStream.java:308) Issue https://issues.apache.org/jira/browse/PDFBOX-1225 handles a similar error: An attempt to Integer.parseString() is made with a value > Integer.MAX_VALUE. Line 541 in CMAPParser.java should probably use Long datatype. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669229#comment-13669229 ] Maruan Sahyoun commented on PDFBOX-1615: Hi Tom, that seems to be an issue introduced in the 1.8.x release. Worked on 1.7.x. It's not because of the splitting itself as if you simply load and save the original file using 1.8.x the issue occurs. We will need to investigate which change caused that regression. BR Maruan > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Taylor updated PDFBOX-1615: --- Attachment: media-4.pdf media-3.pdf media-2.pdf media-1.pdf media-0.pdf media.pdf Hi, I couldn't see how to attach files to the Jira issue, attaching the original file (media.pdf) and the first few pages that I split using PDFSplit tool where you see the problem. Regards /Tom Excosoft • Tom Taylor Information Manager Kammakargatan 7, SE-111 40 Stockholm Phone & Mobile +46 (0) 761 993181 Email tom.tay...@excosoft.se www.excosoft.se > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > Attachments: media-0.pdf, media-1.pdf, media-2.pdf, media-3.pdf, > media-4.pdf, media.pdf > > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1615) Color map not correctly copied when PDF file is split
[ https://issues.apache.org/jira/browse/PDFBOX-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669202#comment-13669202 ] Maruan Sahyoun commented on PDFBOX-1615: Yes, please attach the original PDF as well as the splitted version. BR Maruan > Color map not correctly copied when PDF file is split > - > > Key: PDFBOX-1615 > URL: https://issues.apache.org/jira/browse/PDFBOX-1615 > Project: PDFBox > Issue Type: Bug > Components: PDModel, Utilities >Affects Versions: 1.8.1 > Environment: Windows 7, 64-bit JVM 1.6.0_29 >Reporter: Tom Taylor > > A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion > in a document. When I split the file using the PDFSplit tool, the same > problem occurs. > On some pages, the color map appears to be altered such that background and > text are rendered in different colors (yellow/lilac instead of > white/blackish). The PDF the customer supplies is probably a scanned document > but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. > The odd thing is that only a subset of pages are affected in a consistent > fashion. > I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1615) Color map not correctly copied when PDF file is split
Tom Taylor created PDFBOX-1615: -- Summary: Color map not correctly copied when PDF file is split Key: PDFBOX-1615 URL: https://issues.apache.org/jira/browse/PDFBOX-1615 Project: PDFBox Issue Type: Bug Components: PDModel, Utilities Affects Versions: 1.8.1 Environment: Windows 7, 64-bit JVM 1.6.0_29 Reporter: Tom Taylor A customer has a pdf file which we split (pdfbox.util.Splitter) for inclusion in a document. When I split the file using the PDFSplit tool, the same problem occurs. On some pages, the color map appears to be altered such that background and text are rendered in different colors (yellow/lilac instead of white/blackish). The PDF the customer supplies is probably a scanned document but the metadata claims it is created using PDF-XChange Viewer 2.5.195.0. The odd thing is that only a subset of pages are affected in a consistent fashion. I can supply the original PDF file on request for you to look at. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1614) Digitally sign PDFs without file system access
[
https://issues.apache.org/jira/browse/PDFBOX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669106#comment-13669106
]
Thomas Chojecki commented on PDFBOX-1614:
-
As I remember, a filesystem-less access was prepared. That's why the save
increment call has two parameter. I will check and cleanup the code.
> Digitally sign PDFs without file system access
> --
>
> Key: PDFBOX-1614
> URL: https://issues.apache.org/jira/browse/PDFBOX-1614
> Project: PDFBox
> Issue Type: Improvement
>Reporter: Thierry Boschat
>
> Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
> I find the sample below to handle it.
> But in this example I have to use a FileInputStream however I want to do it
> only through streams (without any file system access). I tried to extends
> FileInputStream to deal with it but I failed. Any tips for me about that
> problem ?
> Thanks.
> File outputDocument = new File("resources/signed" + document.getName());
> FileInputStream fis = new FileInputStream(document);
> FileOutputStream fos = new FileOutputStream(outputDocument);
> int c;
> while ((c = fis.read(buffer)) != -1)
> {
> fos.write(buffer, 0, c);
> }
> fis.close();
> fis = new FileInputStream(outputDocument);
> // load document
> PDDocument doc = PDDocument.load(document);
> // create signature dictionary
> PDSignature signature = new PDSignature();
> signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
> // subfilter for basic and PAdES Part 2 signatures
> signature.setSubFilter(PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED);
> signature.setName("signer name");
> signature.setLocation("signer location");
> signature.setReason("reason for signature");
> // the signing date, needed for valid signature
> signature.setSignDate(Calendar.getInstance());
> // register signature dictionary and sign interface
> doc.addSignature(signature, this);
> // write incremental (only for signing purpose)
> doc.saveIncremental(fis, fos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PDFBOX-1614) Digitally sign PDFs without file system access
[
https://issues.apache.org/jira/browse/PDFBOX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki reassigned PDFBOX-1614:
---
Assignee: Thomas Chojecki
> Digitally sign PDFs without file system access
> --
>
> Key: PDFBOX-1614
> URL: https://issues.apache.org/jira/browse/PDFBOX-1614
> Project: PDFBox
> Issue Type: Improvement
>Reporter: Thierry Boschat
>Assignee: Thomas Chojecki
>
> Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
> I find the sample below to handle it.
> But in this example I have to use a FileInputStream however I want to do it
> only through streams (without any file system access). I tried to extends
> FileInputStream to deal with it but I failed. Any tips for me about that
> problem ?
> Thanks.
> File outputDocument = new File("resources/signed" + document.getName());
> FileInputStream fis = new FileInputStream(document);
> FileOutputStream fos = new FileOutputStream(outputDocument);
> int c;
> while ((c = fis.read(buffer)) != -1)
> {
> fos.write(buffer, 0, c);
> }
> fis.close();
> fis = new FileInputStream(outputDocument);
> // load document
> PDDocument doc = PDDocument.load(document);
> // create signature dictionary
> PDSignature signature = new PDSignature();
> signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
> // subfilter for basic and PAdES Part 2 signatures
> signature.setSubFilter(PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED);
> signature.setName("signer name");
> signature.setLocation("signer location");
> signature.setReason("reason for signature");
> // the signing date, needed for valid signature
> signature.setSignDate(Calendar.getInstance());
> // register signature dictionary and sign interface
> doc.addSignature(signature, this);
> // write incremental (only for signing purpose)
> doc.saveIncremental(fis, fos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1614) Digitally sign PDFs without file system access
[
https://issues.apache.org/jira/browse/PDFBOX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-1614:
Component/s: Writing
PDModel
Affects Version/s: 1.8.1
> Digitally sign PDFs without file system access
> --
>
> Key: PDFBOX-1614
> URL: https://issues.apache.org/jira/browse/PDFBOX-1614
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel, Writing
>Affects Versions: 1.8.1
>Reporter: Thierry Boschat
>Assignee: Thomas Chojecki
>
> Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
> I find the sample below to handle it.
> But in this example I have to use a FileInputStream however I want to do it
> only through streams (without any file system access). I tried to extends
> FileInputStream to deal with it but I failed. Any tips for me about that
> problem ?
> Thanks.
> File outputDocument = new File("resources/signed" + document.getName());
> FileInputStream fis = new FileInputStream(document);
> FileOutputStream fos = new FileOutputStream(outputDocument);
> int c;
> while ((c = fis.read(buffer)) != -1)
> {
> fos.write(buffer, 0, c);
> }
> fis.close();
> fis = new FileInputStream(outputDocument);
> // load document
> PDDocument doc = PDDocument.load(document);
> // create signature dictionary
> PDSignature signature = new PDSignature();
> signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
> // subfilter for basic and PAdES Part 2 signatures
> signature.setSubFilter(PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED);
> signature.setName("signer name");
> signature.setLocation("signer location");
> signature.setReason("reason for signature");
> // the signing date, needed for valid signature
> signature.setSignDate(Calendar.getInstance());
> // register signature dictionary and sign interface
> doc.addSignature(signature, this);
> // write incremental (only for signing purpose)
> doc.saveIncremental(fis, fos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1614) Digitally sign PDFs without file system access
Thierry Boschat created PDFBOX-1614:
---
Summary: Digitally sign PDFs without file system access
Key: PDFBOX-1614
URL: https://issues.apache.org/jira/browse/PDFBOX-1614
Project: PDFBox
Issue Type: Improvement
Reporter: Thierry Boschat
Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
I find the sample below to handle it.
But in this example I have to use a FileInputStream however I want to do it
only through streams (without any file system access). I tried to extends
FileInputStream to deal with it but I failed. Any tips for me about that
problem ?
Thanks.
File outputDocument = new File("resources/signed" + document.getName());
FileInputStream fis = new FileInputStream(document);
FileOutputStream fos = new FileOutputStream(outputDocument);
int c;
while ((c = fis.read(buffer)) != -1)
{
fos.write(buffer, 0, c);
}
fis.close();
fis = new FileInputStream(outputDocument);
// load document
PDDocument doc = PDDocument.load(document);
// create signature dictionary
PDSignature signature = new PDSignature();
signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
// subfilter for basic and PAdES Part 2 signatures
signature.setSubFilter(PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED);
signature.setName("signer name");
signature.setLocation("signer location");
signature.setReason("reason for signature");
// the signing date, needed for valid signature
signature.setSignDate(Calendar.getInstance());
// register signature dictionary and sign interface
doc.addSignature(signature, this);
// write incremental (only for signing purpose)
doc.saveIncremental(fis, fos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
