subject:"Last commit in SVN HEAD broke the PDFWriter"

Re: Last commit in SVN HEAD broke the PDFWriter

2015-07-27 Thread 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

Re: Last commit in SVN HEAD broke the PDFWriter

2015-07-27 Thread 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

2015-07-27 Thread 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: Last commit in SVN HEAD broke the PDFWriter

2015-07-27 Thread 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

Re: Last commit in SVN HEAD broke the PDFWriter

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

2015-07-27 Thread 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

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

Re: Last commit in SVN HEAD broke the PDFWriter

11 matches

Site Navigation

Mail list logo

Footer information