Hi,
> Am 01.08.2016 um 15:54 schrieb David Hill <[email protected]>:
>
> John,
>
> The bug does still exist, hence my continued need to override the class in
> question.
>
> "Subclassing huge swathes of internal code" gets the job done without waiting
> for a future release. Making it harder for users to work around issues might
> increase patch submission but doesn't sound like the best overall solution.
>
> The bug is that when merging two PDFs, if the first PDF doesn't have any tags
> and the second one does, tags are lost. Tags are a critical feature for 508
> compliance.
>
from your description you have issues when merging tags. But you are also
changing the code to merge AcroForms. So are you having issues with both parts?
BR
Maruan
> I don't have a patch, and I haven't fixed the latest version yet, but from
> version 1.8.6 your code from PDFMergerUtility.appendDocument line 327 that
> looks like this
>
> PDAcroForm destAcroForm = destCatalog.getAcroForm();
> PDAcroForm srcAcroForm = srcCatalog.getAcroForm();
> if (destAcroForm == null)
> {
> cloner.cloneForNewDocument(srcAcroForm);
> destCatalog.setAcroForm(srcAcroForm);
> }
>
> we changed to this
>
> PDAcroForm destAcroForm = destCatalog.getAcroForm();
> PDAcroForm srcAcroForm = srcCatalog.getAcroForm();
> if (srcAcroForm != null && destAcroForm == null)
> {
> destAcroForm = new PDAcroForm(destination);
> PDResources res = new PDResources();
> destAcroForm.setDefaultResources(res);
> destination.getDocumentCatalog().setAcroForm(destAcroForm);
>
> cloner.cloneForNewDocument(srcAcroForm);
> mergeAcroForm(cloner, destAcroForm, srcAcroForm);
> }
>
>
> and line 554 which was
>
> kDictLevel0.setItem(COSName.K, newKArray);
> kDictLevel0.setItem(COSName.P, destStructTree);
> kDictLevel0.setItem(COSName.S, new
> COSString(STRUCTURETYPE_DOCUMENT));
> destStructTree.setK(kDictLevel0);
>
> we apparently changed to
>
> //Kids of source document (insert)
> List<Object> addKids = srcStructTree.getKids();
> for (Object k : addKids) {
> ((PDStructureElement) k).setParent(destStructTree);
> destStructTree.appendKid((PDStructureElement) k);
> }
>
>
> I did not make the original changes and I have not yet attempted to correct
> version 2.0.2 but without these changes we have failing tests looking for
> tags and have verified the output files are missing tags.
>
> Thank you.
> Dave
>
> _____________________
>
> ___________________
> From: John Hewson [[email protected]]
> Sent: Saturday, July 30, 2016 2:47 AM
> To: [email protected]
> Subject: {External} Re: upgrading to 2.x - package private class
> PDFieldFactory?
>
>> On 29 Jul 2016, at 06:09, David Hill <[email protected]> wrote:
>>
>>
>> I am upgrading a project from 1.8.6 to the 2.0.2 version of PDFBox and
>> everything went reasonably well except that we made use of PDFieldFactory
>>
>> PDField destField = PDFieldFactory.createField
>>
>> Everything in PDFieldFactory used to be public but now it is all package
>> private.
>>
>> I tried to copy the code for that method into our project and found that all
>> of the various PDField objects being created were also package private.
>>
>> It looks like the code we have came from overriding and copying
>> PDFMergerUtility.appendDocument to fix an apparent bug.
>> PDFMergerUtility.appendDocument makes a call to PDFieldFactory.createField.
>>
>> I could continue to force my way around this issue but I have to wonder if
>> this was intentional.
>
> Yep. Subclassing huge swathes of internal code isn't a great solution to
> fixing a bug in an open source project. We'd happily take a patch for the bug
> if it still exists.
>
> -- John
>
>>
>> Dave
>
> ________________________________
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this e-mail in error please notify the originator of the
> message. This footer also confirms that this e-mail message has been scanned
> for the presence of computer viruses. Any views expressed in this message are
> those of the individual sender, except where the sender specifies and with
> authority, states them to be the views of Iowa Student Loan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
