[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 10:10 PM:
---

Okay, the solution is more complex than I thought because before the merge I do 
not have a PDDocument and need to create a COSStream for the XMP meta data. 
Furthermore, it is non-trivial to set the creator property for XMP. I had to 
look into the XMPBox source code in order to find out how to do that. Maybe you 
want to publish this as an example if you find it useful and comprehensive. I 
think it is important to return something to the community, especially because 
Tilman supported me so well.

{code}
package de.scrum_master.pdf_tools;

import org.apache.pdfbox.cos.COSStream;
import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import org.apache.pdfbox.pdmodel.PDDocumentInformation;
import org.apache.pdfbox.pdmodel.common.PDMetadata;
import org.apache.xmpbox.XMPMetadata;
import org.apache.xmpbox.schema.DublinCoreSchema;
import org.apache.xmpbox.schema.PDFAIdentificationSchema;
import org.apache.xmpbox.schema.XMPBasicSchema;
import org.apache.xmpbox.type.AgentNameType;
import org.apache.xmpbox.type.BadFieldValueException;
import org.apache.xmpbox.xml.XmpSerializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.xml.transform.TransformerException;
import java.io.*;
import java.util.Calendar;
import java.util.List;

public class PDFMerger {
  private final static Logger logger = LoggerFactory.getLogger(PDFMerger.class);

  /**
   * Modified {@link ByteArrayOutputStream} whose {@link 
StateExposingByteArrayOutputStream#toByteArray()}
   * method directly returns its internal byte buffer in order to avoid 
in-memory copies during PDF merge.
   * 
   * Please use carefully!
   */
  private static class StateExposingByteArrayOutputStream extends 
ByteArrayOutputStream {
@Override
public synchronized byte[] toByteArray() {
  return buf;
}
  }

  /**
   * Creates a compound PDF document from a list of input documents
   * 
   * The merged document is PDF/A-1b compliant, provided the source documents 
are as well.
   * It contains document properties title, creator and subject, currently 
hard-coded.
   *
   * @param sources list of source PDF document streams
   * @return compound PDF document as a readable stream
   * @throws IOException if anything goes wrong during PDF merge
   */
  public InputStream merge(final List sources) throws IOException {
String title = "My title";
String creator = "Alexander Kriegisch";
String subject = "Subject with umlauts ÄÖÜ";

try (
  ByteArrayOutputStream mergedPDFOutputStream = new 
StateExposingByteArrayOutputStream();
  COSStream cosStream = new COSStream()
) {
  PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, 
mergedPDFOutputStream);

  // PDF and XMP properties must be identical, otherwise document is not 
PDF/A compliant
  PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(title, 
creator, subject);
  PDMetadata xmpMetadata = createXMPMetadata(cosStream, title, creator, 
subject);
  pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
  pdfMerger.setDestinationMetadata(xmpMetadata);

  logger.trace("Merging {} source documents into one PDF", sources.size());
  pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
  logger.trace("PDF merge successful, size = {} bytes", 
mergedPDFOutputStream.size());

  return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0, 
mergedPDFOutputStream.size());

} catch (BadFieldValueException | TransformerException e) {
  throw new IOException("PDF merge problem", e);
} finally {
  for (InputStream source : sources) {
try {
  source.close();
} catch (IOException e) {}
  }
}
  }

  private PDFMergerUtility createPDFMergerUtility(
List sources,
ByteArrayOutputStream mergedPDFOutputStream
  ) {
logger.trace("Initialising PDF merge utility");
PDFMergerUtility pdfMerger = new PDFMergerUtility();
pdfMerger.addSources(sources);
pdfMerger.setDestinationStream(mergedPDFOutputStream);
return pdfMerger;
  }

  private PDDocumentInformation createPDFDocumentInfo(
String title, String creator, String subject
  ) {
logger.trace("Setting document info (title, author, subject) for merged 
PDF");
PDDocumentInformation documentInformation = new PDDocumentInformation();
documentInformation.setTitle(title);
documentInformation.setCreator(creator);
documentInformation.setSubject(subject);
return documentInformation;
  }

  private PDMetadata createXMPMetadata(
COSStream cosStream,
String title, String creator, String subject
  )

[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 10:08 PM:
---

Okay, the solution is more complex than I thought because before the merge I do 
not have a PDDocument and need to create a COSStream for the XMP meta data. 
Furthermore, it is non-trivial to set the creator property for XMP. I had to 
look into the XMPBox source code in order to find out how to do that. Maybe you 
want to publish this as an example if you find it useful and comprehensive. I 
think it is important to return something to the community, especially because 
Tilman supported me so well.

{code}
package de.scrum_master.pdf_tools;

import org.apache.pdfbox.cos.COSStream;
import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import org.apache.pdfbox.pdmodel.PDDocumentInformation;
import org.apache.pdfbox.pdmodel.common.PDMetadata;
import org.apache.xmpbox.XMPMetadata;
import org.apache.xmpbox.schema.DublinCoreSchema;
import org.apache.xmpbox.schema.PDFAIdentificationSchema;
import org.apache.xmpbox.schema.XMPBasicSchema;
import org.apache.xmpbox.type.AgentNameType;
import org.apache.xmpbox.type.BadFieldValueException;
import org.apache.xmpbox.xml.XmpSerializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.xml.transform.TransformerException;
import java.io.*;
import java.util.Calendar;
import java.util.List;

public class PDFMerger {
  private final static Logger logger = LoggerFactory.getLogger(PDFMerger.class);

  /**
   * Modified {@link ByteArrayOutputStream} whose {@link 
StateExposingByteArrayOutputStream#toByteArray()}
   * method directly returns its internal byte buffer in order to avoid 
in-memory copies during PDF merge.
   * 
   * Please use carefully!
   */
  private static class StateExposingByteArrayOutputStream extends 
ByteArrayOutputStream {
@Override
public synchronized byte[] toByteArray() {
  return buf;
}
  }

  /**
   * Creates a compound PDF document from a list of input documents
   * 
   * The merged document is PDF/A-1b compliant, provided the source documents 
are as well.
   * It contains document properties title, creator and subject, currently 
hard-coded.
   *
   * @param sources list of source PDF document streams
   * @return compound PDF document as a readable stream
   * @throws if anything goes wrong during PDF merge
   */
  public InputStream merge(final List sources) throws IOException {
String title = "My title";
String creator = "Alexander Kriegisch";
String subject = "Subject with umlauts ÄÖÜ";

try (
  ByteArrayOutputStream mergedPDFOutputStream = new 
StateExposingByteArrayOutputStream();
  COSStream cosStream = new COSStream()
) {
  PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, 
mergedPDFOutputStream);

  // PDF and XMP properties must be identical, otherwise document is not 
PDF/A compliant
  PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(title, 
creator, subject);
  PDMetadata xmpMetadata = createXMPMetadata(cosStream, title, creator, 
subject);
  pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
  pdfMerger.setDestinationMetadata(xmpMetadata);

  logger.trace("Merging {} source documents into one PDF", sources.size());
  pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
  logger.trace("PDF merge successful, size = {} bytes", 
mergedPDFOutputStream.size());

  return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0, 
mergedPDFOutputStream.size());

} catch (BadFieldValueException | TransformerException e) {
  throw new IOException("PDF merge problem", e);
} finally {
  for (InputStream source : sources) {
try {
  source.close();
} catch (IOException e) {}
  }
}
  }

  private PDFMergerUtility createPDFMergerUtility(
List sources,
ByteArrayOutputStream mergedPDFOutputStream
  ) {
logger.trace("Initialising PDF merge utility");
PDFMergerUtility pdfMerger = new PDFMergerUtility();
pdfMerger.addSources(sources);
pdfMerger.setDestinationStream(mergedPDFOutputStream);
return pdfMerger;
  }

  private PDDocumentInformation createPDFDocumentInfo(
String title, String creator, String subject
  ) {
logger.trace("Setting document info (title, author, subject) for merged 
PDF");
PDDocumentInformation documentInformation = new PDDocumentInformation();
documentInformation.setTitle(title);
documentInformation.setCreator(creator);
documentInformation.setSubject(subject);
return documentInformation;
  }

  private PDMetadata createXMPMetadata(
COSStream cosStream,
String title, String creator, String subject
  )
throws

Re: [VOTE] Release Apache PDFBox 2.0.1

2016-04-22 Thread Maruan Sahyoun 
+1

Maruan

> Am 22.04.2016 um 19:15 schrieb Andreas Lehmkuehler :
> 
> Hi,
> 
> a candidate for the PDFBox 2.0.1 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/pdfbox/2.0.1/
> 
> The release candidate is a zip archive of the sources in:
> 
>http://svn.apache.org/repos/asf/pdfbox/tags/2.0.1/
> 
> The SHA1 checksum of the archive is d136549561196c2844eea2c06d70f064b836ca56.
> 
> Please vote on releasing this package as Apache PDFBox 2.0.1.
> 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 2.0.1
>[ ] -1 Do not release this package because...
> 
> Here is my +1
> 
> BR
> Andreas Lehmkühler
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: [VOTE] Release Apache PDFBox 2.0.1

2016-04-22 Thread Tilman Hausherr 

+1

Tilman

Am 22.04.2016 um 19:15 schrieb Andreas Lehmkuehler:

Hi,

a candidate for the PDFBox 2.0.1 release is available at:

https://dist.apache.org/repos/dist/dev/pdfbox/2.0.1/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/pdfbox/tags/2.0.1/

The SHA1 checksum of the archive is 
d136549561196c2844eea2c06d70f064b836ca56.


Please vote on releasing this package as Apache PDFBox 2.0.1.
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 2.0.1
[ ] -1 Do not release this package because...

Here is my +1

BR
Andreas Lehmkühler

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2941) Improve PDFDebugger (2)

2016-04-22 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr updated PDFBOX-2941:

Description: 
This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came up 
in GSoC2015, ideas that were not implemented due to lack of time, and new ideas.
- save modified PDFs
- refactor PDFDebugger.java
- render glyphs of fonts
- editing in hex viewer
- ✓ refactor StreamPane to share stream filtering among Text view and hex view
- ✓ password dialog when hitting protected PDF
- remove nodes (e.g. elements from a COSDictionary)
- show "pretty" XML
- delete array or dictionary elements
- edit & keep content streams
- load content streams
- display filtered streams even if the unfiltered stream is corrupt 
(PDFBOX-2976)
- ✓ display the "caused by" part exception stack trace (nested exceptions)
- ✓ keep zoom
- integrate DrawPrintTextLocations into rendering
- integrate area text extraction with a mouse-created rectangle that shows the 
coordinates in a status line
- ✓ show permission flags of {{Encrypt/P}} entry
- ✓ show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219 in 
PDF spec


  was:
This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came up 
in GSoC2015, ideas that were not implemented due to lack of time, and new ideas.
- save modified PDFs
- refactor PDFDebugger.java
- render glyphs of fonts
- editing in hex viewer
- ✓ refactor StreamPane to share stream filtering among Text view and hex view
- ✓ password dialog when hitting protected PDF
- remove nodes (e.g. elements from a COSDictionary)
- show "pretty" XML
- delete array or dictionary elements
- edit & keep content streams
- load content streams
- display filtered streams even if the unfiltered stream is corrupt 
(PDFBOX-2976)
- ✓ display the "caused by" part exception stack trace (nested exceptions)
- ✓ keep zoom
- integrate DrawPrintTextLocations into rendering
- integrate area text extraction with a mouse-created rectangle that shows the 
coordinates in a status line
- ✓ show permission flags of {{Encrypt/P}} entry
- show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219 in 
PDF spec



> Improve PDFDebugger (2)
> ---
>
> Key: PDFBOX-2941
> URL: https://issues.apache.org/jira/browse/PDFBOX-2941
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: gs-bugzilla694570.pdf, keep_zoom.diff, osx-tabs.png, 
> screenshot_debugger_new.png, screenshot_debugger_not_aligned.png, 
> screenshot_debugger_old.png, screenshot_w7_fontsize.png, 
> separate_filter_choice_from_text_hex_views.diff, sonar_qube_resolve.diff, 
> sonar_qube_resolve_25_08.diff
>
>
> This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came 
> up in GSoC2015, ideas that were not implemented due to lack of time, and new 
> ideas.
> - save modified PDFs
> - refactor PDFDebugger.java
> - render glyphs of fonts
> - editing in hex viewer
> - ✓ refactor StreamPane to share stream filtering among Text view and hex view
> - ✓ password dialog when hitting protected PDF
> - remove nodes (e.g. elements from a COSDictionary)
> - show "pretty" XML
> - delete array or dictionary elements
> - edit & keep content streams
> - load content streams
> - display filtered streams even if the unfiltered stream is corrupt 
> (PDFBOX-2976)
> - ✓ display the "caused by" part exception stack trace (nested exceptions)
> - ✓ keep zoom
> - integrate DrawPrintTextLocations into rendering
> - integrate area text extraction with a mouse-created rectangle that shows 
> the coordinates in a status line
> - ✓ show permission flags of {{Encrypt/P}} entry
> - ✓ show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219 
> in PDF spec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2941) Improve PDFDebugger (2)

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1740607 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1740607 ]

PDFBOX-2941: support signature flags

> Improve PDFDebugger (2)
> ---
>
> Key: PDFBOX-2941
> URL: https://issues.apache.org/jira/browse/PDFBOX-2941
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: gs-bugzilla694570.pdf, keep_zoom.diff, osx-tabs.png, 
> screenshot_debugger_new.png, screenshot_debugger_not_aligned.png, 
> screenshot_debugger_old.png, screenshot_w7_fontsize.png, 
> separate_filter_choice_from_text_hex_views.diff, sonar_qube_resolve.diff, 
> sonar_qube_resolve_25_08.diff
>
>
> This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came 
> up in GSoC2015, ideas that were not implemented due to lack of time, and new 
> ideas.
> - save modified PDFs
> - refactor PDFDebugger.java
> - render glyphs of fonts
> - editing in hex viewer
> - ✓ refactor StreamPane to share stream filtering among Text view and hex view
> - ✓ password dialog when hitting protected PDF
> - remove nodes (e.g. elements from a COSDictionary)
> - show "pretty" XML
> - delete array or dictionary elements
> - edit & keep content streams
> - load content streams
> - display filtered streams even if the unfiltered stream is corrupt 
> (PDFBOX-2976)
> - ✓ display the "caused by" part exception stack trace (nested exceptions)
> - ✓ keep zoom
> - integrate DrawPrintTextLocations into rendering
> - integrate area text extraction with a mouse-created rectangle that shows 
> the coordinates in a status line
> - ✓ show permission flags of {{Encrypt/P}} entry
> - show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219 in 
> PDF spec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2941) Improve PDFDebugger (2)

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

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

PDFBOX-2941: support signature flags

> Improve PDFDebugger (2)
> ---
>
> Key: PDFBOX-2941
> URL: https://issues.apache.org/jira/browse/PDFBOX-2941
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: gs-bugzilla694570.pdf, keep_zoom.diff, osx-tabs.png, 
> screenshot_debugger_new.png, screenshot_debugger_not_aligned.png, 
> screenshot_debugger_old.png, screenshot_w7_fontsize.png, 
> separate_filter_choice_from_text_hex_views.diff, sonar_qube_resolve.diff, 
> sonar_qube_resolve_25_08.diff
>
>
> This is a follow-up issue to PDFBOX-2530 to implement extra ideas that came 
> up in GSoC2015, ideas that were not implemented due to lack of time, and new 
> ideas.
> - save modified PDFs
> - refactor PDFDebugger.java
> - render glyphs of fonts
> - editing in hex viewer
> - ✓ refactor StreamPane to share stream filtering among Text view and hex view
> - ✓ password dialog when hitting protected PDF
> - remove nodes (e.g. elements from a COSDictionary)
> - show "pretty" XML
> - delete array or dictionary elements
> - edit & keep content streams
> - load content streams
> - display filtered streams even if the unfiltered stream is corrupt 
> (PDFBOX-2976)
> - ✓ display the "caused by" part exception stack trace (nested exceptions)
> - ✓ keep zoom
> - integrate DrawPrintTextLocations into rendering
> - integrate area text extraction with a mouse-created rectangle that shows 
> the coordinates in a status line
> - ✓ show permission flags of {{Encrypt/P}} entry
> - show signature flags of {{Root/AcroForm/SigFlags}} entry, see Table 219 in 
> PDF spec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3030) Enhance documentation for PDFBox 2.0.0

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit e6bfaa4623868111cfea1c80ed51e3b77383bce2 in pdfbox-docs's branch 
refs/heads/master from [~msahyoun]
[ https://git-wip-us.apache.org/repos/asf?p=pdfbox-docs.git;h=e6bfaa4 ]

PDFBOX-3030: add info about removed PDField.getWidget() to migration guide


> Enhance documentation for PDFBox 2.0.0
> --
>
> Key: PDFBOX-3030
> URL: https://issues.apache.org/jira/browse/PDFBOX-3030
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Affects Versions: 2.0.0
>Reporter: Maruan Sahyoun
>Assignee: Maruan Sahyoun
> Attachments: TGH-16862c48-6b0b-410e-8fc6-b1d9f4418ecc.htm
>
>
> Task to track enhancements to the documentation or website as part of PDFBox 
> 2.0.0
> - update javadoc (current as of writing)
> - migration guide 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[VOTE] Release Apache PDFBox 2.0.1

2016-04-22 Thread Andreas Lehmkuehler 

Hi,

a candidate for the PDFBox 2.0.1 release is available at:

https://dist.apache.org/repos/dist/dev/pdfbox/2.0.1/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/pdfbox/tags/2.0.1/

The SHA1 checksum of the archive is d136549561196c2844eea2c06d70f064b836ca56.

Please vote on releasing this package as Apache PDFBox 2.0.1.
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 2.0.1
[ ] -1 Do not release this package because...

Here is my +1

BR
Andreas Lehmkühler

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: [VOTE] Release Apache PDFBox 1.8.12

2016-04-22 Thread Maruan Sahyoun 
+1

thanks for again handling the process.

BR
Maruan
> Am 22.04.2016 um 18:50 schrieb Andreas Lehmkuehler :
> 
> Hi,
> 
> a candidate for the PDFBox 1.8.12 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/pdfbox/1.8.12/
> 
> The release candidate is a zip archive of the sources in:
> 
>http://svn.apache.org/repos/asf/pdfbox/tags/1.8.12/
> 
> The SHA1 checksum of the archive is 9367a4580806013dfb416da46c21d3a1a05ac9d7.
> 
> Please vote on releasing this package as Apache PDFBox 1.8.12.
> 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.12
>[ ] -1 Do not release this package because...
> 
> Here is my +1
> 
> BR
> Andreas Lehmkühler
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: [VOTE] Release Apache PDFBox 1.8.12

2016-04-22 Thread Tilman Hausherr 

+1


Tilman

Am 22.04.2016 um 18:50 schrieb Andreas Lehmkuehler:

Hi,

a candidate for the PDFBox 1.8.12 release is available at:

https://dist.apache.org/repos/dist/dev/pdfbox/1.8.12/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/pdfbox/tags/1.8.12/

The SHA1 checksum of the archive is 
9367a4580806013dfb416da46c21d3a1a05ac9d7.


Please vote on releasing this package as Apache PDFBox 1.8.12.
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.12
[ ] -1 Do not release this package because...

Here is my +1

BR
Andreas Lehmkühler

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: [VOTE] Release Apache PDFBox 1.8.12

2016-04-22 Thread rey malahay 
+1

On 22 April 2016 at 10:50, Andreas Lehmkuehler  wrote:

> Hi,
>
> a candidate for the PDFBox 1.8.12 release is available at:
>
> https://dist.apache.org/repos/dist/dev/pdfbox/1.8.12/
>
> The release candidate is a zip archive of the sources in:
>
> http://svn.apache.org/repos/asf/pdfbox/tags/1.8.12/
>
> The SHA1 checksum of the archive is
> 9367a4580806013dfb416da46c21d3a1a05ac9d7.
>
> Please vote on releasing this package as Apache PDFBox 1.8.12.
> 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.12
> [ ] -1 Do not release this package because...
>
> Here is my +1
>
> BR
> Andreas Lehmkühler
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
>
>


-- 
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono

[VOTE] Release Apache PDFBox 1.8.12

2016-04-22 Thread Andreas Lehmkuehler 

Hi,

a candidate for the PDFBox 1.8.12 release is available at:

https://dist.apache.org/repos/dist/dev/pdfbox/1.8.12/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/pdfbox/tags/1.8.12/

The SHA1 checksum of the archive is 9367a4580806013dfb416da46c21d3a1a05ac9d7.

Please vote on releasing this package as Apache PDFBox 1.8.12.
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.12
[ ] -1 Do not release this package because...

Here is my +1

BR
Andreas Lehmkühler

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Resolved] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr resolved PDFBOX-3323.
-
   Resolution: Fixed
 Assignee: Tilman Hausherr
Fix Version/s: 2.1.0
   2.0.1

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>Assignee: Tilman Hausherr
>  Labels: merge, metadata
> Fix For: 2.0.1, 2.1.0
>
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-3323:
-

Ok, committed. I'll comment on the rest at a later time.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>Assignee: Tilman Hausherr
>  Labels: merge, metadata
> Fix For: 2.0.1, 2.1.0
>
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1740546 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1740546 ]

PDFBOX-3323: add possibility to set info and xmp after merge

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1740540 from [~msahyoun] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1740540 ]

PDFBOX-2852: fix Javadoc for PDField.getWidgets()

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: winansiencoding.patch, winansiencoding2.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2016-04-22 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1740539 from [~msahyoun] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1740539 ]

PDFBOX-2852: fix Javadoc for PDField.getWidgets()

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: winansiencoding.patch, winansiencoding2.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3321) ASCII stream data size is increased when written

2016-04-22 Thread Petras (JIRA) 

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

Petras edited comment on PDFBOX-3321 at 4/22/16 2:12 PM:
-

Yes, it avoids being indirect as long as nobody set 
_COSInteger.ZERO.setDirect(false)_ before calling 
_PDVisibleSigProperties#buildSignature()_ (due to the way COSWriter checks the 
*/Length* entry directness). If set, the length become indirect, the stream 
data size is increased by 2 in the final document, but at least we do not get 
*/Length* value mismatch with the actual stream data length. The value, though 
indirect, matches the stream data length.


was (Author: abyss):
Yes, it avoids being direct as long as nobody set 
_COSInteger.ZERO.setDirect(false)_ before calling 
_PDVisibleSigProperties#buildSignature()_ (due to the way COSWriter checks the 
*/Length* entry directness). If set, the length become indirect, the stream 
data size is increased by 2 in the final document, but at least we do not get 
*/Length* value mismatch with the actual stream data length. The value, though 
indirect, matches the stream data length.

> ASCII stream data size is increased when written
> 
>
> Key: PDFBOX-3321
> URL: https://issues.apache.org/jira/browse/PDFBOX-3321
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing
>Affects Versions: 1.8.11
>Reporter: Petras
>Assignee: Tilman Hausherr
>Priority: Critical
>  Labels: signature, streams
> Fix For: 1.8.12
>
>
> This bug is quite complicated and was discovered when visual signatures were 
> used along with parsing of the document with Preflight before signing. 
> I dig a bit trying to investigate this bug nature as the bug does not appear 
> regularly. It appears that it manifests itself under such conditions:
> # Document is parsed when opened (ex. by Preflight) and entry with number 
> value is detected, which is marked as direct by 
> _BaseParser.parseCOSDictionary(BaseParser.java:381)_;
> # Stream with ASCII filter is created or present in document having the same 
> length as the number found in step 1 (ex. when visual signature is created by 
> calling _SignatureOptions#setVisualSignature()_);
> # While written _COSWriter_ checks the stream length by its _direct_ 
> property. If */Length* is present and is flaged as direct, it is not 
> recalculated when written.
> As a result, when doucument is written, the stream length is changed: written 
> stream is increased by 2 bytes, while */Length* entry still indicate the 
> original length. That violates PDF requirements for the */Length* entry:
> bq. The number of bytes from the beginning of the line following the keyword 
> *stream* to the last byte just before the keyword *endstream*. (There may be 
> an additional EOL marker, preceding *endstream*, that is not included in the 
> count and is not logically part of the stream data.)
> These bugs complement to this effect:
> * PDFBOX-3320 & PDFBOX-2685, as number used for stream length is marked as 
> direct;
> * _BaseParser.parseCOSStream(BaseParser.java:490)_ parses ASCII stream using 
> _EndstreamOutputStream_ class, which always includes all characters till the 
> *endstream* keyword, though CRLF preceding *endstream* is not part of the 
> stream data;
> * _COSWriter_ checks the stream length by its _direct_ property, even though 
> it could be set as indirect via _COSObject_. As it is flaged as direct due to 
> mutability of cached COSNumber, the stream length is not recalculated.
> As _COSWriter_ always adds CRLF at the end of the stream, the final stream 
> data increased by 2 bytes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 1:45 PM:
--

Okay, the solution is more complex than I thought because before the merge I do 
not have a PDDocument and need to create a COSStream for the XMP meta data. 
Furthermore, it is non-trivial to set the creator property for XMP. I had to 
look into the XMPBox source code in order to find out how to do that. Maybe you 
want to publish this as an example if you find it useful and comprehensive. I 
think it is important to return something to the community, especially because 
Tilman supported me so well.

{code}
package de.scrum_master.pdf_tools;

import org.apache.pdfbox.cos.COSStream;
import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import org.apache.pdfbox.pdmodel.PDDocumentInformation;
import org.apache.pdfbox.pdmodel.common.PDMetadata;
import org.apache.xmpbox.XMPMetadata;
import org.apache.xmpbox.schema.DublinCoreSchema;
import org.apache.xmpbox.schema.PDFAIdentificationSchema;
import org.apache.xmpbox.schema.XMPBasicSchema;
import org.apache.xmpbox.type.AgentNameType;
import org.apache.xmpbox.type.BadFieldValueException;
import org.apache.xmpbox.xml.XmpSerializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.xml.transform.TransformerException;
import java.io.*;
import java.util.Calendar;
import java.util.List;

public class PDFMerger {
  private final static Logger logger = LoggerFactory.getLogger(PDFMerger.class);

  /**
   * Modified {@link ByteArrayOutputStream} whose {@link 
StateExposingByteArrayOutputStream#toByteArray()}
   * method directly returns its internal byte buffer in order to avoid 
im-memory copies during PDF merge.
   * 
   * Please use carefully!
   */
  private static class StateExposingByteArrayOutputStream extends 
ByteArrayOutputStream {
@Override
public synchronized byte[] toByteArray() {
  return buf;
}
  }

  /**
   * Creates a compound PDF document from a list of input documents
   * 
   * The merged document is PDF/A-1b compliant, provided the source documents 
are as well.
   * It contains document properties title, creator and subject, currently 
hard-coded.
   *
   * @param sources list of source PDF document streams
   * @return compound PDF document as a readable stream
   * @throws if anything goes wrong during PDF merge
   */
  public InputStream merge(final List sources) throws IOException {
String title = "My title";
String creator = "Alexander Kriegisch";
String subject = "Subject with umlauts ÄÖÜ";

try (
  ByteArrayOutputStream mergedPDFOutputStream = new 
StateExposingByteArrayOutputStream();
  COSStream cosStream = new COSStream()
) {
  PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, 
mergedPDFOutputStream);

  // PDF and XMP properties must be identical, otherwise document is not 
PDF/A compliant
  PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(title, 
creator, subject);
  PDMetadata xmpMetadata = createXMPMetadata(cosStream, title, creator, 
subject);
  pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
  pdfMerger.setDestinationMetadata(xmpMetadata);

  logger.trace("Merging {} source documents into one PDF", sources.size());
  pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
  logger.trace("PDF merge successful, size = {} bytes", 
mergedPDFOutputStream.size());

  return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0, 
mergedPDFOutputStream.size());

} catch (BadFieldValueException | TransformerException e) {
  throw new IOException("PDF merge problem", e);
} finally {
  for (InputStream source : sources) {
try {
  source.close();
} catch (IOException e) {}
  }
}
  }

  private PDFMergerUtility createPDFMergerUtility(
List sources,
ByteArrayOutputStream mergedPDFOutputStream
  ) {
logger.trace("Initialising PDF merge utility");
PDFMergerUtility pdfMerger = new PDFMergerUtility();
pdfMerger.addSources(sources);
pdfMerger.setDestinationStream(mergedPDFOutputStream);
return pdfMerger;
  }

  private PDDocumentInformation createPDFDocumentInfo(
String title, String creator, String subject
  ) {
logger.trace("Setting document info (title, author, subject) for merged 
PDF");
PDDocumentInformation documentInformation = new PDDocumentInformation();
documentInformation.setTitle(title);
documentInformation.setCreator(creator);
documentInformation.setSubject(subject);
return documentInformation;
  }

  private PDMetadata createXMPMetadata(
COSStream cosStream,
String title, String creator, String subject
  )
throws

[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 1:45 PM:
--

Okay, the solution is more complex than I thought because before the merge I do 
not have a PDDocument and need to create a COSStream for the XMP meta data. 
Furthermore, it is non-trivial to set the creator property for XMP. I had to 
look into the XMPBox source code in order to find out how to do that. Maybe you 
want to publish this as an example if you find it useful and comprehensive. I 
think it is important to return something to the community, especially because 
Tilman supported me so well.

{code}
package de.scrum_master.pdf_tools;

import org.apache.pdfbox.cos.COSStream;
import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import org.apache.pdfbox.pdmodel.PDDocumentInformation;
import org.apache.pdfbox.pdmodel.common.PDMetadata;
import org.apache.xmpbox.XMPMetadata;
import org.apache.xmpbox.schema.DublinCoreSchema;
import org.apache.xmpbox.schema.PDFAIdentificationSchema;
import org.apache.xmpbox.schema.XMPBasicSchema;
import org.apache.xmpbox.type.AgentNameType;
import org.apache.xmpbox.type.BadFieldValueException;
import org.apache.xmpbox.xml.XmpSerializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.xml.transform.TransformerException;
import java.io.*;
import java.util.Calendar;
import java.util.List;

public class PDFMerger {
  private final static Logger logger = LoggerFactory.getLogger(PDFMerger.class);

  /**
   * Modified {@link ByteArrayOutputStream} whose {@link 
StateExposingByteArrayOutputStream#toByteArray()}
   * method directly returns its internal byte buffer in order to avoid 
im-memory copies during PDF merge.
   * 
   * Please use carefully!
   */
  private static class StateExposingByteArrayOutputStream extends 
ByteArrayOutputStream {
@Override
public synchronized byte[] toByteArray() {
  return buf;
}
  }

  /**
   * Creates a compound PDF document from a list of input documents
   * 
   * The merged document is PDF/A-1b compliant, provided the source documents 
are as well.
   * It contains document properties title, creator and subject, currently 
hard-coded.
   *
   * @param sources list of source PDF document streams
   * @return compound PDF document as a readable stream
   * @throws if anything goes wrong during PDF merge
   */
  public InputStream merge(final List sources) throws IOException {
String title = "My title";
String creator = "Alexander Kriegisch";
String subject = "Subject with umlauts ÄÖÜ";

try (
  ByteArrayOutputStream mergedPDFOutputStream = new 
StateExposingByteArrayOutputStream();
  COSStream cosStream = new COSStream()
) {
  PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, 
mergedPDFOutputStream);

  // PDF and XMP properties must be identical, otherwise document is not 
PDF/A compliant
  PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(title, 
creator, subject);
  PDMetadata xmpMetadata = createXMPMetadata(cosStream, title, creator, 
subject);
  pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
  pdfMerger.setDestinationMetadata(xmpMetadata);

  logger.trace("Merging {} source documents into one PDF", sources.size());
  pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
  logger.trace("PDF merge successful, size = {} bytes", 
mergedPDFOutputStream.size());

  return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0, 
mergedPDFOutputStream.size());

} catch (BadFieldValueException | TransformerException e) {
  throw new IOException("PDF merge problem", e);
} finally {
  for (InputStream source : sources) {
try {
  source.close();
} catch (IOException e) {}
  }
}
  }

  private PDFMergerUtility createPDFMergerUtility(
List sources,
ByteArrayOutputStream mergedPDFOutputStream
  ) {
logger.trace("Initialising PDF merge utility");
PDFMergerUtility pdfMerger = new PDFMergerUtility();
pdfMerger.addSources(sources);
pdfMerger.setDestinationStream(mergedPDFOutputStream);
return pdfMerger;
  }

  private PDDocumentInformation createPDFDocumentInfo(
String title, String creator, String subject
  ) {
logger.trace("Setting document info (title, author, subject) for merged 
PDF");
PDDocumentInformation documentInformation = new PDDocumentInformation();
documentInformation.setTitle(title);
documentInformation.setCreator(creator);
documentInformation.setSubject(subject);
return documentInformation;
  }

  private PDMetadata createXMPMetadata(
COSStream cosStream,
String title, String creator, String subject
  )
throws

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch commented on PDFBOX-3323:
-

Okay, the solution is more complex than I thought because before the merge I do 
not have a PDDocument and need to create a COSStream for the XMP meta data. 
Furthermore, it is non-trivial to set the creator property for XMP. I had to 
look into the XMPBox source code in order to find out how to do that. Maybe you 
want to publish this as an example if you find it useful and comprehensive. I 
think it is important to return something to the community, especially because 
Tilman supported me so well.

{code}
package de.scrum_master.pdf_tools;

import org.apache.pdfbox.cos.COSStream;
import org.apache.pdfbox.io.MemoryUsageSetting;
import org.apache.pdfbox.multipdf.PDFMergerUtility;
import org.apache.pdfbox.pdmodel.PDDocumentInformation;
import org.apache.pdfbox.pdmodel.common.PDMetadata;
import org.apache.xmpbox.XMPMetadata;
import org.apache.xmpbox.schema.DublinCoreSchema;
import org.apache.xmpbox.schema.PDFAIdentificationSchema;
import org.apache.xmpbox.schema.XMPBasicSchema;
import org.apache.xmpbox.type.AgentNameType;
import org.apache.xmpbox.type.BadFieldValueException;
import org.apache.xmpbox.xml.XmpSerializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.xml.transform.TransformerException;
import java.io.*;
import java.util.Calendar;
import java.util.List;

public class PDFMerger {
  private final static Logger logger = LoggerFactory.getLogger(PDFMerger.class);

  /**
   * Modified {@link ByteArrayOutputStream} whose {@link 
StateExposingByteArrayOutputStream#toByteArray()}
   * method directly returns its internal byte buffer in order to avoid 
im-memory copies during PDF merge.
   * 
   * Please use carefully!
   */
  private static class StateExposingByteArrayOutputStream extends 
ByteArrayOutputStream {
@Override
public synchronized byte[] toByteArray() {
  return buf;
}
  }

  /**
   * Creates a compound PDF document from a list of input documents
   * 
   * The merged document is PDF/A-1b compliant, provided the source documents 
are as well.
   * It contains document properties title, creator and subject, currently 
hard-coded.
   *
   * @param sources list of source PDF document streams
   * @return compound PDF document as a readable stream
   * @throws if anything goes wrong during PDF merge
   */
  public InputStream merge(final List sources) throws IOException {
String title = "My title";
String creator = "Alexander Kriegisch";
String subject = "Subject with umlauts ÄÖÜ";

try (
  ByteArrayOutputStream mergedPDFOutputStream = new 
StateExposingByteArrayOutputStream();
  COSStream cosStream = new COSStream()
) {
  PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, 
mergedPDFOutputStream);

  // PDF and XMP properties must be identical, otherwise document is not 
PDF/A compliant
  PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(title, 
creator, subject);
  PDMetadata xmpMetadata = createXMPMetadata(cosStream, title, creator, 
subject);
  pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
  pdfMerger.setDestinationMetadata(xmpMetadata);

  logger.trace("Merging {} source documents into one PDF", sources.size());
  pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
  logger.trace("PDF merge successful, size = {} bytes", 
mergedPDFOutputStream.size());

  return new ByteArrayInputStream(mergedPDFOutputStream.toByteArray(), 0, 
mergedPDFOutputStream.size());

} catch (BadFieldValueException | TransformerException e) {
  throw new IOException("PDF merge problem", e);
} finally {
  for (InputStream source : sources) {
try {
  source.close();
} catch (IOException e) {}
  }
}
  }

  private PDFMergerUtility createPDFMergerUtility(
List sources,
ByteArrayOutputStream mergedPDFOutputStream
  ) {
logger.trace("Initialising PDF merge utility");
PDFMergerUtility pdfMerger = new PDFMergerUtility();
pdfMerger.addSources(sources);
pdfMerger.setDestinationStream(mergedPDFOutputStream);
return pdfMerger;
  }

  private PDDocumentInformation createPDFDocumentInfo(
String title, String creator, String subject
  ) {
logger.trace("Setting document info (title, author, subject) for merged 
PDF");
PDDocumentInformation documentInformation = new PDDocumentInformation();
documentInformation.setTitle(title);
documentInformation.setCreator(creator);
documentInformation.setSubject(subject);
return documentInformation;
  }

  private PDMetadata createXMPMetadata(
COSStream cosStream,
String title, String creator, String subject
  )
throws BadFieldValueException, TransformerException, IOException
  {

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch commented on PDFBOX-3323:
-

This is not an option, I have to set title, subject and creator. This is a 
requirement. I found a solution now, but it is rather complex. See my next 
comment.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-3323:
-

use null as parameter, i.e. {{setCreator(null)}}.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 9:02 AM:
--

I tried the Preflight tool.
* First it said it could not parse the metadata. Via 
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ I found 
out that somehow a tag like {{Umlaut ö}} is written to the PDF file in ISO 
instead of UTF-8 encoding, which looks like a problem in PDFBox (my input data 
are in UTF-8).
* Then, after removing the German umlaut, still Preflight is not satisfied, 
saying: _"7.2 : Error on MetaData, CreatorTool present in the document catalog 
dictionary can't be found in XMP information (Property is not defined)"_ It 
looks as though PDFBox writes a document info item I have never set and which 
has no (un)setter method in class {{PDDocumentInformation}}.


was (Author: kriegaex):
I tried the Preflight tool.
* First it said it could not parse the metadata. Via 
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ I found 
out that somehow a tag like {{Umlaut ö}} is written to the PDF file in ISO 
instead of UTF-8 encoding, which looks like a problem in PDFBox (my input data 
are in UTF-8).
* Then, after removing the German umlaut, still Preflight is not satisfied, 
saying: _"7.2 : Error on MetaData, CreatorTool present in the document catalog 
dictionary can't be found in XMP information (Property is not defined)"_ It 
looks as though PDFBox writes a document info item I have never set and which 
has not (un)setter method in class {{PDDocumentInformation}}.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: Jira Spam - And changes made as a result.

2016-04-22 Thread Andreas Lehmkühler 


> Petr Slabý  hat am 22. April 2016 um 10:49 geschrieben:
> 
> 
> Hi,
> does that mean that you are free of bug reports from now on? That is a great 
> invention, we should make the same in our company internal JIRA, that would 
> save a lot of work to me :-)
Hopefully nowone already filed a patent on that ;-)
> 
> Can you please add me to a group which is allowed to post issues, too?
Done. 

BR
Andreas
> 
> Best regards,
> Petr.
> 
> -Původní zpráva- 
> From: Andreas Lehmkühler
> Sent: Friday, April 22, 2016 10:31 AM
> To: dev@pdfbox.apache.org
> Subject: Re: FW: Jira Spam - And changes made as a result.
> 
> 
> Hi,
> 
> > Simon Steiner  hat am 22. April 2016 um 10:17
> > geschrieben:
> >
> >
> > Hi,
> >
> >
> >
> > I cant create/comment on pdfbox issues anymore.
> I've added your account ot the contributor group so that you should be able 
> to
> comment/creat again
> 
> BR
> Andreas
> 
> >
> >
> >
> > Thanks
> >
> >
> >
> > From: Gav [mailto:gmcdon...@apache.org]
> > Sent: 22 April 2016 01:14
> > To: infrastruct...@apache.org Infrastructure 
> > Subject: Jira Spam - And changes made as a result.
> >
> >
> >
> > Hi All,
> >
> > Apologies for notifying you after the fact.
> >
> > Earlier today (slowing down to a halt about 1/2 hr ago due to our changes) 
> > we
> > had a
> >
> > big Spam attack directed at the ASF Jira instance.
> >
> > Many project were affected, including :-
> >
> > TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
> > AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .
> >
> > During the process we ended up banning 27 IP addresses , deleted well over 
> > 200
> > tickets, and about 2 dozen user accounts.
> >
> > The spammers were creating accounts using the normal system and going 
> > through
> > the required captchas.
> >
> > In addition to the ban hammer and deletions and to prevent more spam 
> > coming
> > in, we changed the 'Default Permissions Scheme' so that anyone in the
> > 'jira-users' group are no longer allowed to 'Create' tickets and are no 
> > longer
> > allowed to 'Comment' on any tickets.
> >
> > Obviously that affects genuine users as well as the spammers, we know 
> > that.
> >
> > Replacement auth instead of jira-users group now includes allowing those 
> > in
> > the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in 
> > jira.
> >
> > Projects would you please assist in making this work - anyone that is not 
> > in
> > any of those roles for your project; and needs access to be able to create
> > issues and comment, please do add their jira id to one of the available 
> > roles.
> > (Let us know if you need assistance in this area)
> >
> > This is a short term solution. For the medium to long term we are working 
> > on
> > providing LDAP authentication for Jira and Confluence through Atlassian 
> > Crowd
> > (likley).
> >
> > If any projects are still being affected, please notify us as you may be 
> > using
> > another permissions scheme to the one altered. Notify us via INFRA jira 
> > ticket
> > or reply to this mail to infrastruct...@apache.org
> >   or join us on hipchat
> > (https://www.hipchat.com/gIjVtYcNy)
> >
> > Any project seriously adversely impacted by our changes please do come 
> > talk to
> > us and we'll see what we can work out.
> >
> > Thanks all for your patience and understanding.
> >
> > Gav... (ASF Infra)
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org 
>

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: Jira Spam - And changes made as a result.

2016-04-22 Thread Petr Slabý 

Hi,
does that mean that you are free of bug reports from now on? That is a great 
invention, we should make the same in our company internal JIRA, that would 
save a lot of work to me :-)


Can you please add me to a group which is allowed to post issues, too?

Best regards,
Petr.

-Původní zpráva- 
From: Andreas Lehmkühler

Sent: Friday, April 22, 2016 10:31 AM
To: dev@pdfbox.apache.org
Subject: Re: FW: Jira Spam - And changes made as a result.


Hi,


Simon Steiner  hat am 22. April 2016 um 10:17
geschrieben:


Hi,



I cant create/comment on pdfbox issues anymore.
I've added your account ot the contributor group so that you should be able 
to

comment/creat again

BR
Andreas





Thanks



From: Gav [mailto:gmcdon...@apache.org]
Sent: 22 April 2016 01:14
To: infrastruct...@apache.org Infrastructure 
Subject: Jira Spam - And changes made as a result.



Hi All,

Apologies for notifying you after the fact.

Earlier today (slowing down to a halt about 1/2 hr ago due to our changes) 
we

had a

big Spam attack directed at the ASF Jira instance.

Many project were affected, including :-

TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .

During the process we ended up banning 27 IP addresses , deleted well over 
200

tickets, and about 2 dozen user accounts.

The spammers were creating accounts using the normal system and going 
through

the required captchas.

In addition to the ban hammer and deletions and to prevent more spam 
coming

in, we changed the 'Default Permissions Scheme' so that anyone in the
'jira-users' group are no longer allowed to 'Create' tickets and are no 
longer

allowed to 'Comment' on any tickets.

Obviously that affects genuine users as well as the spammers, we know 
that.


Replacement auth instead of jira-users group now includes allowing those 
in
the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in 
jira.


Projects would you please assist in making this work - anyone that is not 
in

any of those roles for your project; and needs access to be able to create
issues and comment, please do add their jira id to one of the available 
roles.

(Let us know if you need assistance in this area)

This is a short term solution. For the medium to long term we are working 
on
providing LDAP authentication for Jira and Confluence through Atlassian 
Crowd

(likley).

If any projects are still being affected, please notify us as you may be 
using
another permissions scheme to the one altered. Notify us via INFRA jira 
ticket

or reply to this mail to infrastruct...@apache.org
  or join us on hipchat
(https://www.hipchat.com/gIjVtYcNy)

Any project seriously adversely impacted by our changes please do come 
talk to

us and we'll see what we can work out.

Thanks all for your patience and understanding.

Gav... (ASF Infra)



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: FW: Jira Spam - And changes made as a result.

2016-04-22 Thread Andreas Lehmkühler 

Hi,

> Simon Steiner  hat am 22. April 2016 um 10:17
> geschrieben:
> 
> 
> Hi,
> 
>  
> 
> I cant create/comment on pdfbox issues anymore.
I've added your account ot the contributor group so that you should be able to
comment/creat again

BR
Andreas

> 
>  
> 
> Thanks
> 
>  
> 
> From: Gav [mailto:gmcdon...@apache.org] 
> Sent: 22 April 2016 01:14
> To: infrastruct...@apache.org Infrastructure 
> Subject: Jira Spam - And changes made as a result.
> 
>  
> 
> Hi All,
> 
> Apologies for notifying you after the fact.
> 
> Earlier today (slowing down to a halt about 1/2 hr ago due to our changes) we
> had a
> 
> big Spam attack directed at the ASF Jira instance.
> 
> Many project were affected, including :-
> 
> TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
> AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .
> 
> During the process we ended up banning 27 IP addresses , deleted well over 200
> tickets, and about 2 dozen user accounts.
> 
> The spammers were creating accounts using the normal system and going through
> the required captchas.
> 
> In addition to the ban hammer and deletions and to prevent more spam coming
> in, we changed the 'Default Permissions Scheme' so that anyone in the
> 'jira-users' group are no longer allowed to 'Create' tickets and are no longer
> allowed to 'Comment' on any tickets.
> 
> Obviously that affects genuine users as well as the spammers, we know that. 
> 
> Replacement auth instead of jira-users group now includes allowing those in
> the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in jira.
> 
> Projects would you please assist in making this work - anyone that is not in
> any of those roles for your project; and needs access to be able to create
> issues and comment, please do add their jira id to one of the available roles.
> (Let us know if you need assistance in this area)
> 
> This is a short term solution. For the medium to long term we are working on
> providing LDAP authentication for Jira and Confluence through Atlassian Crowd
> (likley).
> 
> If any projects are still being affected, please notify us as you may be using
> another permissions scheme to the one altered. Notify us via INFRA jira ticket
> or reply to this mail to infrastruct...@apache.org
>   or join us on hipchat
> (https://www.hipchat.com/gIjVtYcNy)
> 
> Any project seriously adversely impacted by our changes please do come talk to
> us and we'll see what we can work out.
> 
> Thanks all for your patience and understanding.
> 
> Gav... (ASF Infra)
>

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch edited comment on PDFBOX-3323 at 4/22/16 8:27 AM:
--

I tried the Preflight tool.
* First it said it could not parse the metadata. Via 
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ I found 
out that somehow a tag like {{Umlaut ö}} is written to the PDF file in ISO 
instead of UTF-8 encoding, which looks like a problem in PDFBox (my input data 
are in UTF-8).
* Then, after removing the German umlaut, still Preflight is not satisfied, 
saying: _"7.2 : Error on MetaData, CreatorTool present in the document catalog 
dictionary can't be found in XMP information (Property is not defined)"_ It 
looks as though PDFBox writes a document info item I have never set and which 
has not (un)setter method in class {{PDDocumentInformation}}.


was (Author: kriegaex):
I tried the Preflight tool.
* First it said it could not parse the metadata. Via 
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ I found 
out that somehow a tag like {{Umlaut ö}} is written to the PDF file is ISO 
instead of UTF-8 encoding, which looks like a problem in PDFBox (my input data 
are in UTF-8).
* Then, after removing the German umlaut, still Preflight is not satisfied, 
saying: _"7.2 : Error on MetaData, CreatorTool present in the document catalog 
dictionary can't be found in XMP information (Property is not defined)"_ It 
looks as though PDFBox writes a document info item I have never set and which 
has not (un)setter method in class {{PDDocumentInformation}}.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3323) Cannot set destination meta data in PDFMergerUtility

2016-04-22 Thread Alexander Kriegisch (JIRA) 

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

Alexander Kriegisch commented on PDFBOX-3323:
-

I tried the Preflight tool.
* First it said it could not parse the metadata. Via 
https://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/ I found 
out that somehow a tag like {{Umlaut ö}} is written to the PDF file is ISO 
instead of UTF-8 encoding, which looks like a problem in PDFBox (my input data 
are in UTF-8).
* Then, after removing the German umlaut, still Preflight is not satisfied, 
saying: _"7.2 : Error on MetaData, CreatorTool present in the document catalog 
dictionary can't be found in XMP information (Property is not defined)"_ It 
looks as though PDFBox writes a document info item I have never set and which 
has not (un)setter method in class {{PDDocumentInformation}}.

> Cannot set destination meta data in PDFMergerUtility
> 
>
> Key: PDFBOX-3323
> URL: https://issues.apache.org/jira/browse/PDFBOX-3323
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 1.8.9, 2.0.0
>Reporter: Alexander Kriegisch
>  Labels: merge, metadata
>
> When merging multiple PDFs into one compound document via 
> {{PDFMergerUtility}}, meta data like title, author, subject cannot be set but 
> seem to be taken from one of the input documents. This is usually not the 
> desired behaviour because as a user I have no direct influence on the meta 
> data. As a user I would like to explicitly set or at least overwrite certain 
> meta data for the destination document. Currently I can only set the 
> destination stream or file name, but not the meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

FW: Jira Spam - And changes made as a result.

2016-04-22 Thread Simon Steiner 
Hi,

 

I cant create/comment on pdfbox issues anymore.

 

Thanks

 

From: Gav [mailto:gmcdon...@apache.org] 
Sent: 22 April 2016 01:14
To: infrastruct...@apache.org Infrastructure 
Subject: Jira Spam - And changes made as a result.

 

Hi All,

Apologies for notifying you after the fact.

Earlier today (slowing down to a halt about 1/2 hr ago due to our changes) we 
had a

big Spam attack directed at the ASF Jira instance.

Many project were affected, including :-

TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS, AIRFLOW, 
ACE, APEXCORE, RANGER and KYLIN .

During the process we ended up banning 27 IP addresses , deleted well over 200 
tickets, and about 2 dozen user accounts.

The spammers were creating accounts using the normal system and going through 
the required captchas.

In addition to the ban hammer and deletions and to prevent more spam coming in, 
we changed the 'Default Permissions Scheme' so that anyone in the 'jira-users' 
group are no longer allowed to 'Create' tickets and are no longer allowed to 
'Comment' on any tickets.

Obviously that affects genuine users as well as the spammers, we know that. 

Replacement auth instead of jira-users group now includes allowing those in the 
'Administrator, PMC, Committer, Contributor and Developer' ROLES in jira.

Projects would you please assist in making this work - anyone that is not in 
any of those roles for your project; and needs access to be able to create 
issues and comment, please do add their jira id to one of the available roles. 
(Let us know if you need assistance in this area)

This is a short term solution. For the medium to long term we are working on 
providing LDAP authentication for Jira and Confluence through Atlassian Crowd 
(likley).

If any projects are still being affected, please notify us as you may be using 
another permissions scheme to the one altered. Notify us via INFRA jira ticket 
or reply to this mail to infrastruct...@apache.org 
  or join us on hipchat 
(https://www.hipchat.com/gIjVtYcNy)

Any project seriously adversely impacted by our changes please do come talk to 
us and we'll see what we can work out.

Thanks all for your patience and understanding.

Gav... (ASF Infra)