pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maruan Sahyoun <sahy...@fileaffairs.de>
Subject Re: Last commit in SVN HEAD broke the PDFWriter
Date Mon, 27 Jul 2015 09:56:29 GMT
Hi,
> Am 27.07.2015 um 11:49 schrieb Andreas Lehmkühler <andreas@lehmi.de>:
> 
> 
> 
>> Roberto Nibali <rnibali@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 <andreas@lehmi.de>
>> wrote:
>> 
>>> 
>>> 
>>>> Andreas Lehmkühler <andreas@lehmi.de> hat am 27. Juli 2015 um 09:37
>>>> geschrieben:
>>>> 
>>>> 
>>>> Hi Roberto,
>>>> 
>>>>> Roberto Nibali <rnibali@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-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
> 


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


Mime
View raw message