Re: Setting PDF Document Restrictions and Security Limitations

[Roberto Nibali]

Hello

I've managed to somehow hardcode the security settings:

On Mon, Jul 27, 2015 at 2:23 PM, Roberto Nibali rnib...@gmail.com wrote:

 Hi

 I'm trying to replicate the document security settings using PDFBox and
 can't seem to get it working at all. This is the code I use:

 private static PDDocument srcDoc;
 private static PDDocument tplDoc;

 @Test
 public static void SimpleTest() throws IOException {
 String ownerPassword = 12345;
 srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
 tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
 tplDoc.setAllSecurityToBeRemoved(true);
 applyDocPermissions(ownerPassword, );
 srcDoc.close();
 tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
 tplDoc.save(ccmig.pdf);
 tplDoc.close();
 }
 public static void applyDocPermissions(String ownerPassword, String 
 userPassword) throws IOException {
 int encKeyLen;
 AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
 AccessPermission destDocAP = new AccessPermission();
 destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
 destDocAP.setCanExtractContent(srcDocAP.canExtractContent());
 
 destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
 destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
 destDocAP.setCanModify(srcDocAP.canModify());
 destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
 destDocAP.setCanPrint(srcDocAP.canPrint());
 destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
 StandardProtectionPolicy policy = new 
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
 encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 tplDoc.setAllSecurityToBeRemoved(false);
 tplDoc.protect(policy);
 }


Using the following function, it works:

public static void applyDocPermissionsHardcoded(String ownerPassword,
String userPassword) throws IOException {
int encKeyLen;

AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
AccessPermission destDocAP = new AccessPermission();
destDocAP.setCanPrint(true);
//destDocAP.setCanPrintDegraded(false);
destDocAP.setCanModify(false);
destDocAP.setCanAssembleDocument(false);
destDocAP.setCanExtractContent(false);
destDocAP.setCanExtractForAccessibility(true);
//Page Extraction = false
destDocAP.setCanModifyAnnotations(false);
destDocAP.setCanFillInForm(true);
//Signing = true
//Creation of Template Pages = true
StandardProtectionPolicy policy = new
StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
}

Let's hope all documents I need to migrate have the same security settings.
For now, this issue does not need to be looked at anymore. What's
funny is that using PDFBox, I cannot modify the
 page extraction, signing or the creation of template pages bits in
the security settings. Is this missing in the implementation?

Cheers

Roberto

Re: Last commit in SVN HEAD broke the PDFWriter

[Maruan Sahyoun]

Hi Roberto,

 Am 27.07.2015 um 12:32 schrieb Roberto Nibali rnib...@gmail.com:
 
 Hi Maruan
 
 Here are the files:
 ​
 ccalt-simple.pdf
 https://drive.google.com/file/d/0B7Bzk_1dcyc5RmcyWVo1ZURyV0k/view?usp=drive_web
 ​​
 cctemp-simple.pdf
 https://drive.google.com/file/d/0B7Bzk_1dcyc5UHUtNWh6ampVMnc/view?usp=drive_web
 ​
 And here is the testNG code portion. I trust you'll get a reproduceable
 setup working based on this.
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
String ownerPassword = ubsforms;
 
srcDoc = PDDocument.load(new File(./ccalt-simple.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp-simple.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig-simple.pdf);
tplDoc.close();
 }
 

got it an are able to reproduce the issue. 

BR
Maruan


 
 Cheers
 Roberto
 
 On Mon, Jul 27, 2015 at 11:56 AM, Maruan Sahyoun sahy...@fileaffairs.de
 wrote:
 
 Hi,
 Am 27.07.2015 um 11:49 schrieb Andreas Lehmkühler andr...@lehmi.de:
 
 
 
 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 10:29
 geschrieben:
 
 
 Hi Andreas
 
 Thanks for the quick reply.
 
 On Mon, Jul 27, 2015 at 9:55 AM, Andreas Lehmkühler andr...@lehmi.de
 wrote:
 
 
 
 Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
 geschrieben:
 
 
 Hi Roberto,
 
 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
 geschrieben:
 
 
 Dear developers
 
 The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The
 result
 is: The file xx.pdf cannot be open; It may be damaged or use a file
 format
 that Preview doesn’t recognize. The same when using Acrobat
 Professional.
 
 Reverting the commit to the old one makes everything work again. What
 is
 the reason for this change?
 
   // use previous startXref value as new PREV value
   trailer.setLong(COSName.PREV, doc.getStartXref());
   //trailer.removeItem(COSName.PREV);
 
 The trailer.removeItem(COSName.PREV) works, the new
 trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
 Thanks for your hint.
 
 Can you be a little bit more specific, please? What kind of pdf did
 you
 try to
 sign? Can you provide us with a sample pdf?
 
 
 As far as I can tell, I'm not trying to sign any document. I'm working
 on a
 tool that migrates form fields from a source document to a new template
 document (containing the same fields, however some CI/CD changes), and
 subsequently saves the document as a new PDF with suffix -migrated.
 
 In fact, I can trigger this behaviour with the following simple code
 (which
 does nothing else than open the source PDF, the template PDF, removes
 the
 security, sets the need for auto-generated appearances, and saves the
 template into a new PDF):
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
   String ownerPassword = limitedHappiness;
   srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
   tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
   tplDoc.setAllSecurityToBeRemoved(true);
   srcDoc.close();
   tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
   tplDoc.save(ccmig.pdf);
   tplDoc.close();
 }
 
 Due to signed NDAs, I cannot send you the PDF. If we can't solve the
 issue, I'll try to generate a stripped down version for you, however
 that's
 going to take a day or so, and I have other pending issues which I'd
 like
 to address first, as the deadline for the final delivery of the tool is
 now
 definitely coming up.
 
 could you provide us with a stripped down version even if the change
 resolves the issue as I tried to replicate it with some sample PDFs I have
 and haven't been able to do so?
 
 BR
 Maruan
 
 OK, I see you are not using an incremental update feature. The name of
 the
 modified method doWriteXRefInc pretends to be limited to incremental
 updates,
 but it isn't.
 
 
 I just had another idea. Can you please check the following change
 
 if (trailer.getItem(COSName.PREV != null))
 {
   trailer.setLong(COSName.PREV, doc.getStartXref())
 }
 
 
 I modified to the following code, so it compiles:
 
 COSDictionary trailer = doc.getTrailer();
 // use previous startXref value as new PREV value
 //trailer.setLong(COSName.PREV, doc.getStartXref());
 //trailer.removeItem(COSName.PREV);
 if (trailer.getItem(COSName.PREV) != null)
 {
   trailer.setLong(COSName.PREV, doc.getStartXref());
 }
 
 No change, it still breaks my simple test case.
 I'm not at home, so that I can't check that myself, but I guess the
 following
 should do the trick
 if (incrementalUpdate)
 {
   trailer.setLong(COSName.PREV, doc.getStartXref());
 }
 
 
 On a side note (not understanding anything about PDFBox internals): Your
 change seems pretty invasive just 

Setting PDF Document Restrictions and Security Limitations

[Roberto Nibali]

Hi

I'm trying to replicate the document security settings using PDFBox and
can't seem to get it working at all. This is the code I use:

private static PDDocument srcDoc;
private static PDDocument tplDoc;

@Test
public static void SimpleTest() throws IOException {
String ownerPassword = 12345;
srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
applyDocPermissions(ownerPassword, );
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig.pdf);
tplDoc.close();
}
public static void applyDocPermissions(String ownerPassword, String
userPassword) throws IOException {
int encKeyLen;
AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
AccessPermission destDocAP = new AccessPermission();
destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
destDocAP.setCanExtractContent(srcDocAP.canExtractContent());

destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
destDocAP.setCanModify(srcDocAP.canModify());
destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
destDocAP.setCanPrint(srcDocAP.canPrint());
destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
StandardProtectionPolicy policy = new
StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
}

The resulting restrictions and security settings are dead wrong, as seen in
these screenshots:

The original PDF:

​​​
 DocumentRestrictionsSummary-OriginalPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5bTZueXlGbHV5RVU/view?usp=drive_web

 DocumentSecurity-OriginalPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5R0VMWjU2a0toUnc/view?usp=drive_web
​

The modified PDF:

​​​
 DocumentRestrictionsSummary-NewPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5by00SzFLcmxHdFk/view?usp=drive_web
​​
 DocumentSecurity-NewPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5TUpqYzBTS0Mxa3c/view?usp=drive_web
​

I have no idea where to look for in the PDFDebugger to figure out how to
set those document options using COS objects. Can anyone point me to the
respective sections please? Also, it seems as if the API in PDFBox does not
allow to set all aspects of those settings, or at least I couldn't find
them.

My basic question: How do I copy the existing document security settings
from the original document to the new one using PDFBox?

Best regards
Roberto

Re: Setting PDF Document Restrictions and Security Limitations

[Maruan Sahyoun]

Hi,

 Am 27.07.2015 um 14:45 schrieb Roberto Nibali rnib...@gmail.com:
 
 Hello
 
 I've managed to somehow hardcode the security settings:
 
 On Mon, Jul 27, 2015 at 2:23 PM, Roberto Nibali rnib...@gmail.com wrote:
 
 Hi
 
 I'm trying to replicate the document security settings using PDFBox and
 can't seem to get it working at all. This is the code I use:
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
String ownerPassword = 12345;
srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
applyDocPermissions(ownerPassword, );
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig.pdf);
tplDoc.close();
 }
 public static void applyDocPermissions(String ownerPassword, String 
 userPassword) throws IOException {
int encKeyLen;
AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
AccessPermission destDocAP = new AccessPermission();
destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
destDocAP.setCanExtractContent(srcDocAP.canExtractContent());

 destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
destDocAP.setCanModify(srcDocAP.canModify());
destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
destDocAP.setCanPrint(srcDocAP.canPrint());
destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
StandardProtectionPolicy policy = new 
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
 }
 
 
 Using the following function, it works:
 
 public static void applyDocPermissionsHardcoded(String ownerPassword,
 String userPassword) throws IOException {
int encKeyLen;
 
AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
AccessPermission destDocAP = new AccessPermission();
destDocAP.setCanPrint(true);
//destDocAP.setCanPrintDegraded(false);
destDocAP.setCanModify(false);
destDocAP.setCanAssembleDocument(false);
destDocAP.setCanExtractContent(false);
destDocAP.setCanExtractForAccessibility(true);
//Page Extraction = false
destDocAP.setCanModifyAnnotations(false);
destDocAP.setCanFillInForm(true);
//Signing = true
//Creation of Template Pages = true
StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
 }
 

can you try


StandardProtectionPolicy policy = new 
StandardProtectionPolicy(ownerPassword, userPassword, null);
int encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
policy.setPermissions(srcDocAP);


Please verify the settings in the details view of the Acrobat security tab.

BR
Maruan



 Let's hope all documents I need to migrate have the same security settings.
 For now, this issue does not need to be looked at anymore. What's
 funny is that using PDFBox, I cannot modify the
 page extraction, signing or the creation of template pages bits in
 the security settings. Is this missing in the implementation?
 
 Cheers
 
 Roberto


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

Re: Last commit in SVN HEAD broke the PDFWriter

[Andreas Lehmkuehler]

Am 27.07.2015 um 12:49 schrieb Roberto Nibali:

Hi Andreas


  Due to signed NDAs, I cannot send you the PDF. If we can't solve the

issue, I'll try to generate a stripped down version for you, however

that's

going to take a day or so, and I have other pending issues which I'd like
to address first, as the deadline for the final delivery of the tool is

now

definitely coming up.

OK, I see you are not using an incremental update feature. The name of the
modified method doWriteXRefInc pretends to be limited to incremental
updates,
but it isn't.



I have uploaded the PDFs here (for a limited time):

​
  ccalt-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5RmcyWVo1ZURyV0k/view?usp=drive_web
​​
  cctemp-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5UHUtNWh6ampVMnc/view?usp=drive_web
​

You should already have the code to reproduce my issue from a previous
email to this thread.





I just had another idea. Can you please check the following change

if (trailer.getItem(COSName.PREV != null))
{
 trailer.setLong(COSName.PREV, doc.getStartXref())
}



I modified to the following code, so it compiles:

COSDictionary trailer = doc.getTrailer();
// use previous startXref value as new PREV value
//trailer.setLong(COSName.PREV, doc.getStartXref());
//trailer.removeItem(COSName.PREV);
if (trailer.getItem(COSName.PREV) != null)
{
 trailer.setLong(COSName.PREV, doc.getStartXref());
}

No change, it still breaks my simple test case.

I'm not at home, so that I can't check that myself, but I guess the
following
should do the trick
if (incrementalUpdate)
{
 trailer.setLong(COSName.PREV, doc.getStartXref());
}



Nope, this does not work either. The following does, but that's probably
not what you had in mind:

if (incrementalUpdate) {
trailer.setLong(COSName.PREV, doc.getStartXref());
} else {
trailer.removeItem(COSName.PREV);
}


That is exacatly what I have in my mind and I've comitted it already. I'm going 
to run some additional tests later.



Cheers
Roberto



Thanks so far,

Andreas


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

Re: Last commit in SVN HEAD broke the PDFWriter

[Roberto Nibali]

Hi Andreas

  Due to signed NDAs, I cannot send you the PDF. If we can't solve the
  issue, I'll try to generate a stripped down version for you, however
 that's
  going to take a day or so, and I have other pending issues which I'd like
  to address first, as the deadline for the final delivery of the tool is
 now
  definitely coming up.
 OK, I see you are not using an incremental update feature. The name of the
 modified method doWriteXRefInc pretends to be limited to incremental
 updates,
 but it isn't.


I have uploaded the PDFs here (for a limited time):

​
 ccalt-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5RmcyWVo1ZURyV0k/view?usp=drive_web
​​
 cctemp-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5UHUtNWh6ampVMnc/view?usp=drive_web
​

You should already have the code to reproduce my issue from a previous
email to this thread.


 
   I just had another idea. Can you please check the following change
  
   if (trailer.getItem(COSName.PREV != null))
   {
   trailer.setLong(COSName.PREV, doc.getStartXref())
   }
  
  
  I modified to the following code, so it compiles:
 
  COSDictionary trailer = doc.getTrailer();
  // use previous startXref value as new PREV value
  //trailer.setLong(COSName.PREV, doc.getStartXref());
  //trailer.removeItem(COSName.PREV);
  if (trailer.getItem(COSName.PREV) != null)
  {
  trailer.setLong(COSName.PREV, doc.getStartXref());
  }
 
  No change, it still breaks my simple test case.
 I'm not at home, so that I can't check that myself, but I guess the
 following
 should do the trick
 if (incrementalUpdate)
 {
 trailer.setLong(COSName.PREV, doc.getStartXref());
 }


Nope, this does not work either. The following does, but that's probably
not what you had in mind:

if (incrementalUpdate) {
   trailer.setLong(COSName.PREV, doc.getStartXref());
} else {
   trailer.removeItem(COSName.PREV);
}

Cheers
Roberto

Re: Setting PDF Document Restrictions and Security Limitations

[Tilman Hausherr]

Am 27.07.2015 um 14:23 schrieb Roberto Nibali:

Hi

I'm trying to replicate the document security settings using PDFBox and
can't seem to get it working at all. This is the code I use:

private static PDDocument srcDoc;
private static PDDocument tplDoc;

@Test
public static void SimpleTest() throws IOException {
 String ownerPassword = 12345;
 srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
 tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);


This is because when opening a document with the owner password, you get 
all permissions. To get restricted permissions, open the document with 
the user password. (usually empty)


Try it... (I haven't tested your files)

Tilman


 tplDoc.setAllSecurityToBeRemoved(true);
 applyDocPermissions(ownerPassword, );
 srcDoc.close();
 tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
 tplDoc.save(ccmig.pdf);
 tplDoc.close();
}
public static void applyDocPermissions(String ownerPassword, String
userPassword) throws IOException {
 int encKeyLen;
 AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
 AccessPermission destDocAP = new AccessPermission();
 destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
 destDocAP.setCanExtractContent(srcDocAP.canExtractContent());
 
destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
 destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
 destDocAP.setCanModify(srcDocAP.canModify());
 destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
 destDocAP.setCanPrint(srcDocAP.canPrint());
 destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
 StandardProtectionPolicy policy = new
StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
 encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 tplDoc.setAllSecurityToBeRemoved(false);
 tplDoc.protect(policy);
}

The resulting restrictions and security settings are dead wrong, as seen in
these screenshots:

The original PDF:

​​​
  DocumentRestrictionsSummary-OriginalPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5bTZueXlGbHV5RVU/view?usp=drive_web

  DocumentSecurity-OriginalPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5R0VMWjU2a0toUnc/view?usp=drive_web
​

The modified PDF:

​​​
  DocumentRestrictionsSummary-NewPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5by00SzFLcmxHdFk/view?usp=drive_web
​​
  DocumentSecurity-NewPDF.png
https://drive.google.com/file/d/0B7Bzk_1dcyc5TUpqYzBTS0Mxa3c/view?usp=drive_web
​

I have no idea where to look for in the PDFDebugger to figure out how to
set those document options using COS objects. Can anyone point me to the
respective sections please? Also, it seems as if the API in PDFBox does not
allow to set all aspects of those settings, or at least I couldn't find
them.

My basic question: How do I copy the existing document security settings
from the original document to the new one using PDFBox?

Best regards
Roberto




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

Re: Setting PDF Document Restrictions and Security Limitations

[Roberto Nibali]

Hi Tilman

On Mon, Jul 27, 2015 at 5:36 PM, Tilman Hausherr thaush...@t-online.de
wrote:

 Am 27.07.2015 um 14:23 schrieb Roberto Nibali:

 Hi

 I'm trying to replicate the document security settings using PDFBox and
 can't seem to get it working at all. This is the code I use:

 private static PDDocument srcDoc;
 private static PDDocument tplDoc;

 @Test
 public static void SimpleTest() throws IOException {
  String ownerPassword = 12345;
  srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
  tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);


 This is because when opening a document with the owner password, you get
 all permissions. To get restricted permissions, open the document with the
 user password. (usually empty)

 Try it... (I haven't tested your files)

 Tilman


And indeed, this worked. The code looks like this now:

public static void SimpleTest() throws IOException {
srcDoc = PDDocument.load(new File(srcDocName), );
tplDoc = PDDocument.load(new File(tplDocName), );
tplDoc.setAllSecurityToBeRemoved(true);
applyDocPermissions(ownerPassword, );
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(outDocName);
tplDoc.close();
}

Thanks. I will now have a look at Maruan's proposal on top of this.

Cheers
Roberto

Re: Setting PDF Document Restrictions and Security Limitations

[Roberto Nibali]

Hi Maruan

On Mon, Jul 27, 2015 at 3:59 PM, Maruan Sahyoun sahy...@fileaffairs.de
wrote:

 Hi,

  Am 27.07.2015 um 14:45 schrieb Roberto Nibali rnib...@gmail.com:
 
  Hello
 
  I've managed to somehow hardcode the security settings:
 
  On Mon, Jul 27, 2015 at 2:23 PM, Roberto Nibali rnib...@gmail.com
 wrote:
 
  Hi
 
  I'm trying to replicate the document security settings using PDFBox and
  can't seem to get it working at all. This is the code I use:
 
  private static PDDocument srcDoc;
  private static PDDocument tplDoc;
 
  @Test
  public static void SimpleTest() throws IOException {
 String ownerPassword = 12345;
 srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
 tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
 tplDoc.setAllSecurityToBeRemoved(true);
 applyDocPermissions(ownerPassword, );
 srcDoc.close();
 tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
 tplDoc.save(ccmig.pdf);
 tplDoc.close();
  }
  public static void applyDocPermissions(String ownerPassword, String
 userPassword) throws IOException {
 int encKeyLen;
 AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
 AccessPermission destDocAP = new AccessPermission();
 destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
 destDocAP.setCanExtractContent(srcDocAP.canExtractContent());
 
 destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
 destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
 destDocAP.setCanModify(srcDocAP.canModify());
 destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
 destDocAP.setCanPrint(srcDocAP.canPrint());
 destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
 StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
 encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 tplDoc.setAllSecurityToBeRemoved(false);
 tplDoc.protect(policy);
  }
 
 
  Using the following function, it works:
 
  public static void applyDocPermissionsHardcoded(String ownerPassword,
  String userPassword) throws IOException {
 int encKeyLen;
 
 AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
 AccessPermission destDocAP = new AccessPermission();
 destDocAP.setCanPrint(true);
 //destDocAP.setCanPrintDegraded(false);
 destDocAP.setCanModify(false);
 destDocAP.setCanAssembleDocument(false);
 destDocAP.setCanExtractContent(false);
 destDocAP.setCanExtractForAccessibility(true);
 //Page Extraction = false
 destDocAP.setCanModifyAnnotations(false);
 destDocAP.setCanFillInForm(true);
 //Signing = true
 //Creation of Template Pages = true
 StandardProtectionPolicy policy = new
  StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
 encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 tplDoc.setAllSecurityToBeRemoved(false);
 tplDoc.protect(policy);
  }
 

 can you try


 StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, null);
 int encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 policy.setPermissions(srcDocAP);


 Please verify the settings in the details view of the Acrobat security tab.


I have just tried it and it works! Thanks, it makes a lot of sense now:

public static void applyDocPermissions(String ownerPassword, String
userPassword) throws IOException {
int encKeyLen;
AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
StandardProtectionPolicy policy = new
StandardProtectionPolicy(ownerPassword, userPassword, null);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
policy.setPermissions(srcDocAP);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
}

Together with Tilman's change, this part of the code is now small and
concise.

Best regards
Roberto

Re: Setting PDF Document Restrictions and Security Limitations

[Roberto Nibali]

Hi Maruan


 @Test
  public static void SimpleTest() throws IOException {
String ownerPassword = 12345;
srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);


For some reason, in the past I had to set this; which is the reason why I
further down had the call to set it false again. Removing this and your
suggestion still works, so the code finally looks very clean and ledgible
with regard to what one would expect.


applyDocPermissions(ownerPassword, );
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig.pdf);
tplDoc.close();
  }
  can you try
 
 
 StandardProtectionPolicy policy = new
  StandardProtectionPolicy(ownerPassword, userPassword, null);
 int encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 policy.setPermissions(srcDocAP);
 
 
  Please verify the settings in the details view of the Acrobat security
 tab.
 
 
  I have just tried it and it works! Thanks, it makes a lot of sense now:
 
  public static void applyDocPermissions(String ownerPassword, String
  userPassword) throws IOException {
 int encKeyLen;
 AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
 StandardProtectionPolicy policy = new
  StandardProtectionPolicy(ownerPassword, userPassword, null);
 encKeyLen = srcDoc.getEncryption().getLength();
 policy.setEncryptionKeyLength(encKeyLen);
 policy.setPermissions(srcDocAP);
 tplDoc.setAllSecurityToBeRemoved(false);
 tplDoc.protect(policy);
  }

 glad it worked. You should also be able to omit the line

tplDoc.setAllSecurityToBeRemoved(false);

 makes it even shorter :-)


Indeed, however only if the above counter-part is also removed. Otherwise,
we get a warning:

Jul 27, 2015 6:49:42 PM org.apache.pdfbox.pdmodel.PDDocument protect
WARNING: do not call setAllSecurityToBeRemoved(true) before calling
protect(), as protect() implies setAllSecurityToBeRemoved(false)

About a month ago, I received the hint that I had to set this in order to
save the PDF to a new file. For unknown reasons, I do not have to fiddle
around with setAllSecurityToBeRemoved() anymore. I'm very glad ;).

Cheers

Roberto

Re: Setting PDF Document Restrictions and Security Limitations

[Tilman Hausherr]

Am 27.07.2015 um 18:50 schrieb Roberto Nibali:

Indeed, however only if the above counter-part is also removed. Otherwise,
we get a warning:

Jul 27, 2015 6:49:42 PM org.apache.pdfbox.pdmodel.PDDocument protect
WARNING: do not call setAllSecurityToBeRemoved(true) before calling
protect(), as protect() implies setAllSecurityToBeRemoved(false)


Heh heh, I included this warning. (Based on problems you had)



About a month ago, I received the hint that I had to set this in order to
save the PDF to a new file.
Yes it is needed if you want an unencrypted file, or if the file was 
encrypted before and not protected again.


Tilman



For unknown reasons, I do not have to fiddle
around with setAllSecurityToBeRemoved() anymore. I'm very glad;).



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

Re: Setting PDF Document Restrictions and Security Limitations

[Maruan Sahyoun]

Hi,

 Am 27.07.2015 um 18:26 schrieb Roberto Nibali rnib...@gmail.com:
 
 Hi Maruan
 
 On Mon, Jul 27, 2015 at 3:59 PM, Maruan Sahyoun sahy...@fileaffairs.de
 wrote:
 
 Hi,
 
 Am 27.07.2015 um 14:45 schrieb Roberto Nibali rnib...@gmail.com:
 
 Hello
 
 I've managed to somehow hardcode the security settings:
 
 On Mon, Jul 27, 2015 at 2:23 PM, Roberto Nibali rnib...@gmail.com
 wrote:
 
 Hi
 
 I'm trying to replicate the document security settings using PDFBox and
 can't seem to get it working at all. This is the code I use:
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
   String ownerPassword = 12345;
   srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
   tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
   tplDoc.setAllSecurityToBeRemoved(true);
   applyDocPermissions(ownerPassword, );
   srcDoc.close();
   tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
   tplDoc.save(ccmig.pdf);
   tplDoc.close();
 }
 public static void applyDocPermissions(String ownerPassword, String
 userPassword) throws IOException {
   int encKeyLen;
   AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
   AccessPermission destDocAP = new AccessPermission();
   destDocAP.setCanAssembleDocument(srcDocAP.canAssembleDocument());
   destDocAP.setCanExtractContent(srcDocAP.canExtractContent());
 
 destDocAP.setCanExtractForAccessibility(srcDocAP.canExtractForAccessibility());
   destDocAP.setCanFillInForm(srcDocAP.canFillInForm());
   destDocAP.setCanModify(srcDocAP.canModify());
   destDocAP.setCanModifyAnnotations(srcDocAP.canModifyAnnotations());
   destDocAP.setCanPrint(srcDocAP.canPrint());
   destDocAP.setCanPrintDegraded(srcDocAP.canPrintDegraded());
   StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
   encKeyLen = srcDoc.getEncryption().getLength();
   policy.setEncryptionKeyLength(encKeyLen);
   tplDoc.setAllSecurityToBeRemoved(false);
   tplDoc.protect(policy);
 }
 
 
 Using the following function, it works:
 
 public static void applyDocPermissionsHardcoded(String ownerPassword,
 String userPassword) throws IOException {
   int encKeyLen;
 
   AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
   AccessPermission destDocAP = new AccessPermission();
   destDocAP.setCanPrint(true);
   //destDocAP.setCanPrintDegraded(false);
   destDocAP.setCanModify(false);
   destDocAP.setCanAssembleDocument(false);
   destDocAP.setCanExtractContent(false);
   destDocAP.setCanExtractForAccessibility(true);
   //Page Extraction = false
   destDocAP.setCanModifyAnnotations(false);
   destDocAP.setCanFillInForm(true);
   //Signing = true
   //Creation of Template Pages = true
   StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, destDocAP);
   encKeyLen = srcDoc.getEncryption().getLength();
   policy.setEncryptionKeyLength(encKeyLen);
   tplDoc.setAllSecurityToBeRemoved(false);
   tplDoc.protect(policy);
 }
 
 
 can you try
 
 
StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, null);
int encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
policy.setPermissions(srcDocAP);
 
 
 Please verify the settings in the details view of the Acrobat security tab.
 
 
 I have just tried it and it works! Thanks, it makes a lot of sense now:
 
 public static void applyDocPermissions(String ownerPassword, String
 userPassword) throws IOException {
int encKeyLen;
AccessPermission srcDocAP = srcDoc.getCurrentAccessPermission();
StandardProtectionPolicy policy = new
 StandardProtectionPolicy(ownerPassword, userPassword, null);
encKeyLen = srcDoc.getEncryption().getLength();
policy.setEncryptionKeyLength(encKeyLen);
policy.setPermissions(srcDocAP);
tplDoc.setAllSecurityToBeRemoved(false);
tplDoc.protect(policy);
 }

glad it worked. You should also be able to omit the line

   tplDoc.setAllSecurityToBeRemoved(false);

makes it even shorter :-)

 
 Together with Tilman's change, this part of the code is now small and
 concise.

good to hear that.

BR
Maruan

 
 Best regards
 Roberto


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

Re: Last commit in SVN HEAD broke the PDFWriter

[Tilman Hausherr]

Am 27.07.2015 um 12:49 schrieb Roberto Nibali:

I have uploaded the PDFs here (for a limited time):

​
  ccalt-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5RmcyWVo1ZURyV0k/view?usp=drive_web
​​
  cctemp-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5UHUtNWh6ampVMnc/view?usp=drive_web
​

You should already have the code to reproduce my issue from a previous
email to this thread.


Thanks.

I was able to reproduce the effect with this code:

public class RobertoNibaliSaveProblem
{
public static void main(String[] args) throws IOException
{
String dir = ..;

PDDocument tplDoc = PDDocument.load(new File(dir, 
cctemp-simple.pdf));

tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(new File(dir,dest.pdf));
tplDoc.close();
PDDocument.load(new File(dir,dest.pdf)).close();
}

}


Sadly, with the bad code, PDFBox doesn't fail, so we can't create a 
test easily. It just prints two log lines:


27.07.2015 20:54:40.006 ERROR [main] 
org.apache.pdfbox.pdfparser.COSParser:1200 - Can't find the object axref 
table/stream at offset 607694
27.07.2015 20:54:40.010 WARN  [main] 
org.apache.pdfbox.pdfparser.XrefTrailerResolver:253 - Did not found XRef 
object pointed to by 'Prev' key at position 0


I was able to display the file with PDFBox. So in this rare case, we're 
better than Adobe Reader!


Tilman



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

Problem Setting Security

[William Heckle]

I am trying to construct a document that everyone can read and it is not 
modifiable.  I have tried many combinations with no success. Using passwords 
and not using passwords; encrypting and not encrypting, every combination 
doesn't matter. I am setting can modify equals false. The original pdf is 
generated from a birt report, it doesn't add a security handler if that is of 
issue. Below is the code that I thought would set the document to disable 
modification and not allow anyone to modify it; however, Acrobat version 10.0.3 
has no issue with writing in the file then printing the modifications. I am 
using version 1.8.9 pdfBox.

PDDocument documentToProtect= PDDocument.load(document);
AccessPermission ap = new AccessPermission();
ap.setCanModify(false);
ap.setReadOnly();
StandardProtectionPolicy policy = new 
StandardProtectionPolicy(StandardProtectionPolicy,, ap);
policy.setEncryptionKeyLength(128);
documentToProtect.protect(policy);
documentToProtect.save(document);
documentToProtect.close();


Bill Heckle
Programmer
TCEQ Information Resources Division
william.hec...@tceq.texas.gov
512.239.0874

Re: Problem Setting Security

[Tilman Hausherr]

Am 27.07.2015 um 21:46 schrieb William Heckle:


I am trying to construct a document that everyone can read and it is 
not modifiable.  I have tried many combinations with no success. Using 
passwords and not using passwords; encrypting and not encrypting, 
every combination doesn’t matter. I am setting can modify equals 
false. The original pdf is generated from a birt report, it doesn’t 
add a security handler if that is of issue. Below is the code that I 
thought would set the document to disable modification and not allow 
anyone to modify it; however, Acrobat version 10.0.3 has no issue with 
writing in the file then printing the modifications. I am using 
version 1.8.9 pdfBox.


PDDocument documentToProtect= PDDocument.load(document);

AccessPermission ap = new AccessPermission();

ap.setCanModify(false);

ap.setReadOnly();

StandardProtectionPolicy policy = new 
StandardProtectionPolicy(StandardProtectionPolicy,, ap);


policy.setEncryptionKeyLength(128);

documentToProtect.protect(policy);

documentToProtect.save(document);

documentToProtect.close();




I tested your code; setCanModify() works as described, however the 
dialog is hard to find in Adobe Reader, i.e. one has to click on 
security, then on details.



setReadOnly() either has no effect, or I can't see it because I don't 
have Acrobat Professional.


However... the javadoc tells:

/**
 * Locks the access permission read only (ie, the setters will have 
no effects).

 * After that, the object cannot be unlocked.
 * This method is used for the currentAccessPermssion of a document 
to avoid

 * users to change access permission.
 */


Tilman

Re: Last commit in SVN HEAD broke the PDFWriter

[Roberto Nibali]

Hi Maruan

Here are the files:
​
 ccalt-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5RmcyWVo1ZURyV0k/view?usp=drive_web
​​
 cctemp-simple.pdf
https://drive.google.com/file/d/0B7Bzk_1dcyc5UHUtNWh6ampVMnc/view?usp=drive_web
​
And here is the testNG code portion. I trust you'll get a reproduceable
setup working based on this.

private static PDDocument srcDoc;
private static PDDocument tplDoc;

@Test
public static void SimpleTest() throws IOException {
String ownerPassword = ubsforms;

srcDoc = PDDocument.load(new File(./ccalt-simple.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp-simple.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig-simple.pdf);
tplDoc.close();
}


Cheers
Roberto

On Mon, Jul 27, 2015 at 11:56 AM, Maruan Sahyoun sahy...@fileaffairs.de
wrote:

 Hi,
  Am 27.07.2015 um 11:49 schrieb Andreas Lehmkühler andr...@lehmi.de:
 
 
 
  Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 10:29
 geschrieben:
 
 
  Hi Andreas
 
  Thanks for the quick reply.
 
  On Mon, Jul 27, 2015 at 9:55 AM, Andreas Lehmkühler andr...@lehmi.de
  wrote:
 
 
 
  Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
  geschrieben:
 
 
  Hi Roberto,
 
  Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
  geschrieben:
 
 
  Dear developers
 
  The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The
  result
  is: The file xx.pdf cannot be open; It may be damaged or use a file
  format
  that Preview doesn’t recognize. The same when using Acrobat
  Professional.
 
  Reverting the commit to the old one makes everything work again. What
  is
  the reason for this change?
 
 // use previous startXref value as new PREV value
 trailer.setLong(COSName.PREV, doc.getStartXref());
 //trailer.removeItem(COSName.PREV);
 
  The trailer.removeItem(COSName.PREV) works, the new
  trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
  Thanks for your hint.
 
  Can you be a little bit more specific, please? What kind of pdf did
 you
  try to
  sign? Can you provide us with a sample pdf?
 
 
  As far as I can tell, I'm not trying to sign any document. I'm working
 on a
  tool that migrates form fields from a source document to a new template
  document (containing the same fields, however some CI/CD changes), and
  subsequently saves the document as a new PDF with suffix -migrated.
 
  In fact, I can trigger this behaviour with the following simple code
 (which
  does nothing else than open the source PDF, the template PDF, removes
 the
  security, sets the need for auto-generated appearances, and saves the
  template into a new PDF):
 
  private static PDDocument srcDoc;
  private static PDDocument tplDoc;
 
  @Test
  public static void SimpleTest() throws IOException {
 String ownerPassword = limitedHappiness;
 srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
 tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
 tplDoc.setAllSecurityToBeRemoved(true);
 srcDoc.close();
 tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
 tplDoc.save(ccmig.pdf);
 tplDoc.close();
  }
 
  Due to signed NDAs, I cannot send you the PDF. If we can't solve the
  issue, I'll try to generate a stripped down version for you, however
 that's
  going to take a day or so, and I have other pending issues which I'd
 like
  to address first, as the deadline for the final delivery of the tool is
 now
  definitely coming up.

 could you provide us with a stripped down version even if the change
 resolves the issue as I tried to replicate it with some sample PDFs I have
 and haven't been able to do so?

 BR
 Maruan

  OK, I see you are not using an incremental update feature. The name of
 the
  modified method doWriteXRefInc pretends to be limited to incremental
 updates,
  but it isn't.
 
 
  I just had another idea. Can you please check the following change
 
  if (trailer.getItem(COSName.PREV != null))
  {
 trailer.setLong(COSName.PREV, doc.getStartXref())
  }
 
 
  I modified to the following code, so it compiles:
 
  COSDictionary trailer = doc.getTrailer();
  // use previous startXref value as new PREV value
  //trailer.setLong(COSName.PREV, doc.getStartXref());
  //trailer.removeItem(COSName.PREV);
  if (trailer.getItem(COSName.PREV) != null)
  {
 trailer.setLong(COSName.PREV, doc.getStartXref());
  }
 
  No change, it still breaks my simple test case.
  I'm not at home, so that I can't check that myself, but I guess the
 following
  should do the trick
  if (incrementalUpdate)
  {
 trailer.setLong(COSName.PREV, doc.getStartXref());
  }
 
 
  On a side note (not understanding anything about PDFBox internals): Your
  change seems pretty invasive just from an outsider's perspective
  interpreting the method's name. Before 

Re: Last commit in SVN HEAD broke the PDFWriter

[Andreas Lehmkühler]

 Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
 geschrieben:
 
 
 Hi Roberto,
 
  Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
  geschrieben:
  
  
  Dear developers
  
  The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The result
  is: The file xx.pdf cannot be open; It may be damaged or use a file format
  that Preview doesn’t recognize. The same when using Acrobat Professional.
  
  Reverting the commit to the old one makes everything work again. What is
  the reason for this change?
  
  // use previous startXref value as new PREV value
  trailer.setLong(COSName.PREV, doc.getStartXref());
  //trailer.removeItem(COSName.PREV);
  
  The trailer.removeItem(COSName.PREV) works, the new
  trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
 Thanks for your hint.
 
 Can you be a little bit more specific, please? What kind of pdf did you try to
 sign? Can you provide us with a sample pdf?

I just had another idea. Can you please check the following change

if (trailer.getItem(COSName.PREV != null))
{
trailer.setLong(COSName.PREV, doc.getStartXref())
}

TIA
Andreas

 
  Best regards
  
  Roberto
 
 BR
 Andreas
 
 -
 To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
 For additional commands, e-mail: users-h...@pdfbox.apache.org


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

Re: Last commit in SVN HEAD broke the PDFWriter

[Roberto Nibali]

Hi Andreas

Thanks for the quick reply.

On Mon, Jul 27, 2015 at 9:55 AM, Andreas Lehmkühler andr...@lehmi.de
wrote:



  Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
  geschrieben:
 
 
  Hi Roberto,
 
   Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
   geschrieben:
  
  
   Dear developers
  
   The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The
 result
   is: The file xx.pdf cannot be open; It may be damaged or use a file
 format
   that Preview doesn’t recognize. The same when using Acrobat
 Professional.
  
   Reverting the commit to the old one makes everything work again. What
 is
   the reason for this change?
  
   // use previous startXref value as new PREV value
   trailer.setLong(COSName.PREV, doc.getStartXref());
   //trailer.removeItem(COSName.PREV);
  
   The trailer.removeItem(COSName.PREV) works, the new
   trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
  Thanks for your hint.
 
  Can you be a little bit more specific, please? What kind of pdf did you
 try to
  sign? Can you provide us with a sample pdf?


As far as I can tell, I'm not trying to sign any document. I'm working on a
tool that migrates form fields from a source document to a new template
document (containing the same fields, however some CI/CD changes), and
subsequently saves the document as a new PDF with suffix -migrated.

In fact, I can trigger this behaviour with the following simple code (which
does nothing else than open the source PDF, the template PDF, removes the
security, sets the need for auto-generated appearances, and saves the
template into a new PDF):

private static PDDocument srcDoc;
private static PDDocument tplDoc;

@Test
public static void SimpleTest() throws IOException {
String ownerPassword = limitedHappiness;
srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig.pdf);
tplDoc.close();
}

 Due to signed NDAs, I cannot send you the PDF. If we can't solve the
issue, I'll try to generate a stripped down version for you, however that's
going to take a day or so, and I have other pending issues which I'd like
to address first, as the deadline for the final delivery of the tool is now
definitely coming up.


 I just had another idea. Can you please check the following change

 if (trailer.getItem(COSName.PREV != null))
 {
 trailer.setLong(COSName.PREV, doc.getStartXref())
 }


I modified to the following code, so it compiles:

COSDictionary trailer = doc.getTrailer();
// use previous startXref value as new PREV value
//trailer.setLong(COSName.PREV, doc.getStartXref());
//trailer.removeItem(COSName.PREV);
if (trailer.getItem(COSName.PREV) != null)
{
trailer.setLong(COSName.PREV, doc.getStartXref());
}

No change, it still breaks my simple test case.

On a side note (not understanding anything about PDFBox internals): Your
change seems pretty invasive just from an outsider's perspective
interpreting the method's name. Before your change, you basically seem to
have removed the COS entry PREV, after your change, you set it to the
position of the xref section. I'm sure you know what you're doing, it just
does not look minimally invasive in what I would call the hotpath of
PDFWriter ;).

Cheers
Roberto

Re: Last commit in SVN HEAD broke the PDFWriter

[Andreas Lehmkühler]

Hi Roberto,

 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28 geschrieben:
 
 
 Dear developers
 
 The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The result
 is: The file xx.pdf cannot be open; It may be damaged or use a file format
 that Preview doesn’t recognize. The same when using Acrobat Professional.
 
 Reverting the commit to the old one makes everything work again. What is
 the reason for this change?
 
 // use previous startXref value as new PREV value
 trailer.setLong(COSName.PREV, doc.getStartXref());
 //trailer.removeItem(COSName.PREV);
 
 The trailer.removeItem(COSName.PREV) works, the new
 trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
Thanks for your hint.

Can you be a little bit more specific, please? What kind of pdf did you try to
sign? Can you provide us with a sample pdf?

 Best regards
 
 Roberto

BR
Andreas

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

Last commit in SVN HEAD broke the PDFWriter

[Roberto Nibali]

Dear developers

The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The result
is: The file xx.pdf cannot be open; It may be damaged or use a file format
that Preview doesn’t recognize. The same when using Acrobat Professional.

Reverting the commit to the old one makes everything work again. What is
the reason for this change?

// use previous startXref value as new PREV value
trailer.setLong(COSName.PREV, doc.getStartXref());
//trailer.removeItem(COSName.PREV);

The trailer.removeItem(COSName.PREV) works, the new
trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.

Best regards

Roberto

Re: Last commit in SVN HEAD broke the PDFWriter

[Andreas Lehmkühler]

 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 10:29 geschrieben:
 
 
 Hi Andreas
 
 Thanks for the quick reply.
 
 On Mon, Jul 27, 2015 at 9:55 AM, Andreas Lehmkühler andr...@lehmi.de
 wrote:
 
 
 
   Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
   geschrieben:
  
  
   Hi Roberto,
  
Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
geschrieben:
   
   
Dear developers
   
The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The
  result
is: The file xx.pdf cannot be open; It may be damaged or use a file
  format
that Preview doesn’t recognize. The same when using Acrobat
  Professional.
   
Reverting the commit to the old one makes everything work again. What
  is
the reason for this change?
   
// use previous startXref value as new PREV value
trailer.setLong(COSName.PREV, doc.getStartXref());
//trailer.removeItem(COSName.PREV);
   
The trailer.removeItem(COSName.PREV) works, the new
trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
   Thanks for your hint.
  
   Can you be a little bit more specific, please? What kind of pdf did you
  try to
   sign? Can you provide us with a sample pdf?
 
 
 As far as I can tell, I'm not trying to sign any document. I'm working on a
 tool that migrates form fields from a source document to a new template
 document (containing the same fields, however some CI/CD changes), and
 subsequently saves the document as a new PDF with suffix -migrated.
 
 In fact, I can trigger this behaviour with the following simple code (which
 does nothing else than open the source PDF, the template PDF, removes the
 security, sets the need for auto-generated appearances, and saves the
 template into a new PDF):
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
 String ownerPassword = limitedHappiness;
 srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
 tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
 tplDoc.setAllSecurityToBeRemoved(true);
 srcDoc.close();
 tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
 tplDoc.save(ccmig.pdf);
 tplDoc.close();
 }
 
  Due to signed NDAs, I cannot send you the PDF. If we can't solve the
 issue, I'll try to generate a stripped down version for you, however that's
 going to take a day or so, and I have other pending issues which I'd like
 to address first, as the deadline for the final delivery of the tool is now
 definitely coming up.
OK, I see you are not using an incremental update feature. The name of the
modified method doWriteXRefInc pretends to be limited to incremental updates,
but it isn't.

 
  I just had another idea. Can you please check the following change
 
  if (trailer.getItem(COSName.PREV != null))
  {
  trailer.setLong(COSName.PREV, doc.getStartXref())
  }
 
 
 I modified to the following code, so it compiles:
 
 COSDictionary trailer = doc.getTrailer();
 // use previous startXref value as new PREV value
 //trailer.setLong(COSName.PREV, doc.getStartXref());
 //trailer.removeItem(COSName.PREV);
 if (trailer.getItem(COSName.PREV) != null)
 {
 trailer.setLong(COSName.PREV, doc.getStartXref());
 }
 
 No change, it still breaks my simple test case.
I'm not at home, so that I can't check that myself, but I guess the following
should do the trick
if (incrementalUpdate)
{
trailer.setLong(COSName.PREV, doc.getStartXref());
}

 
 On a side note (not understanding anything about PDFBox internals): Your
 change seems pretty invasive just from an outsider's perspective
 interpreting the method's name. Before your change, you basically seem to
 have removed the COS entry PREV, after your change, you set it to the
 position of the xref section. I'm sure you know what you're doing, it just
 does not look minimally invasive in what I would call the hotpath of
 PDFWriter ;).
 
 Cheers
 Roberto

BR
Andreas

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

Re: Last commit in SVN HEAD broke the PDFWriter

[Maruan Sahyoun]

Hi,
 Am 27.07.2015 um 11:49 schrieb Andreas Lehmkühler andr...@lehmi.de:
 
 
 
 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 10:29 geschrieben:
 
 
 Hi Andreas
 
 Thanks for the quick reply.
 
 On Mon, Jul 27, 2015 at 9:55 AM, Andreas Lehmkühler andr...@lehmi.de
 wrote:
 
 
 
 Andreas Lehmkühler andr...@lehmi.de hat am 27. Juli 2015 um 09:37
 geschrieben:
 
 
 Hi Roberto,
 
 Roberto Nibali rnib...@gmail.com hat am 27. Juli 2015 um 09:28
 geschrieben:
 
 
 Dear developers
 
 The last commit 1692730 by lehmi, 18:36, broke the PDFWriter. The
 result
 is: The file xx.pdf cannot be open; It may be damaged or use a file
 format
 that Preview doesn’t recognize. The same when using Acrobat
 Professional.
 
 Reverting the commit to the old one makes everything work again. What
 is
 the reason for this change?
 
// use previous startXref value as new PREV value
trailer.setLong(COSName.PREV, doc.getStartXref());
//trailer.removeItem(COSName.PREV);
 
 The trailer.removeItem(COSName.PREV) works, the new
 trailer.setLong(COSName.PREV, doc.getStartXref()) code does not.
 Thanks for your hint.
 
 Can you be a little bit more specific, please? What kind of pdf did you
 try to
 sign? Can you provide us with a sample pdf?
 
 
 As far as I can tell, I'm not trying to sign any document. I'm working on a
 tool that migrates form fields from a source document to a new template
 document (containing the same fields, however some CI/CD changes), and
 subsequently saves the document as a new PDF with suffix -migrated.
 
 In fact, I can trigger this behaviour with the following simple code (which
 does nothing else than open the source PDF, the template PDF, removes the
 security, sets the need for auto-generated appearances, and saves the
 template into a new PDF):
 
 private static PDDocument srcDoc;
 private static PDDocument tplDoc;
 
 @Test
 public static void SimpleTest() throws IOException {
String ownerPassword = limitedHappiness;
srcDoc = PDDocument.load(new File(./ccalt.pdf), ownerPassword);
tplDoc = PDDocument.load(new File(./cctemp.pdf), ownerPassword);
tplDoc.setAllSecurityToBeRemoved(true);
srcDoc.close();
tplDoc.getDocumentCatalog().getAcroForm().setNeedAppearances(true);
tplDoc.save(ccmig.pdf);
tplDoc.close();
 }
 
 Due to signed NDAs, I cannot send you the PDF. If we can't solve the
 issue, I'll try to generate a stripped down version for you, however that's
 going to take a day or so, and I have other pending issues which I'd like
 to address first, as the deadline for the final delivery of the tool is now
 definitely coming up.

could you provide us with a stripped down version even if the change resolves 
the issue as I tried to replicate it with some sample PDFs I have and haven't 
been able to do so?

BR
Maruan

 OK, I see you are not using an incremental update feature. The name of the
 modified method doWriteXRefInc pretends to be limited to incremental 
 updates,
 but it isn't.
 
 
 I just had another idea. Can you please check the following change
 
 if (trailer.getItem(COSName.PREV != null))
 {
trailer.setLong(COSName.PREV, doc.getStartXref())
 }
 
 
 I modified to the following code, so it compiles:
 
 COSDictionary trailer = doc.getTrailer();
 // use previous startXref value as new PREV value
 //trailer.setLong(COSName.PREV, doc.getStartXref());
 //trailer.removeItem(COSName.PREV);
 if (trailer.getItem(COSName.PREV) != null)
 {
trailer.setLong(COSName.PREV, doc.getStartXref());
 }
 
 No change, it still breaks my simple test case.
 I'm not at home, so that I can't check that myself, but I guess the following
 should do the trick
 if (incrementalUpdate)
 {
trailer.setLong(COSName.PREV, doc.getStartXref());
 }
 
 
 On a side note (not understanding anything about PDFBox internals): Your
 change seems pretty invasive just from an outsider's perspective
 interpreting the method's name. Before your change, you basically seem to
 have removed the COS entry PREV, after your change, you set it to the
 position of the xref section. I'm sure you know what you're doing, it just
 does not look minimally invasive in what I would call the hotpath of
 PDFWriter ;).
 
 Cheers
 Roberto
 
 BR
 Andreas
 
 -
 To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
 For additional commands, e-mail: users-h...@pdfbox.apache.org
 


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