I have an issue where in a internal process based on an XFAPDF file needs to be converted into a standard PDF with attachments for eSign. That part works great, but the attachments are all converting into PDF files and I need at least some of them to be maintained in their native format as this is a requirement of the deliverable to the partner. I am using the invoke 'DDX' object to add the attachments, is there another method that I should be using? Is there some setting that I am missing that would prevent the 'DDX' object from running the attachments through PDF Generator?
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @jCaltrans
the DDX per se is ok, you would not even need the mimetype. I used a static PDF and added an xlxs file and it showed up allright.
I have a feeling that your extraction of those attachments already goes wrong.
I did a quick DDX only approach which extracts and adds. The file types remain what they were.
<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
<FileAttachments result="attachmentInfo.xml" nameKeys="*" extract="true">
<PDF source="doc3.pdf"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<PDF result="outDoc">
<FileAttachments source="doc3.pdf_attach.0000.0001">
<File filename="testattach.xlsx"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<PDF source="3"/>
</PDF>
</DDX>
This pulls attachments from an XFA PDF and then I can use it to add to a static PDF.
The naming of the attachments source is generic. When you generate your DDX you can dynamically set it.
Assembler service calls PDFG at the time of conversion, by default so not sure if its possible to bypass this step but you can explicitly specify the mimetype and encoding of the file attachment to ensure the filetype is intact after the conversion.
<PDF result="doc3.pdf"> <PDF source="doc1.pdf"/> <PDF source="doc2.pdf"/> <FileAttachments source="Testing.txt"> <File filename="Testing.txt" mimetype="text/plain"/> <FilenameEncoding encoding="ISO-8859-1"/> </FileAttachments> </PDF> </PDF>
Hope this helps!
So how will the assembly work?
if there is a a combination of pdf and non pdf file types in the ddx?
.
All I am trying to do is add attachments to a PDF file in a application process, the PDF has been flattened into a standard PDF file with tags for eSign and the attachments were connected to the XFA PDF file before it was flattened. I can do all kinds of great things with attachments up to this point, such as add them to XFA PDF's, and tasks or even read the XML from an Excel file, but I am stymied by something that seams rather simple to do everywhere else. Is there a Java library from Adobe that can handle this, if so I can use it in a script object to add the function, at the moment I am looking at a library from iText. Does anyone have any suggestions for a better library?
sorry- I am not sure what the use case is? are you trying to add attachments to pdf?
I am getting attachments from an XFA form and then applying those to the flattened version of the PDF file and they need to not all be converted to PDF's. Here is an image of the process that I am using so far. Is there another method for applying those attachments to the flat PDF file within a process workflow?
what do you want to do with the file that are not converted to PDF?
Include them as an attachment on the PDF so they can be used by a partner outside the organisation. What and how they are used are out of scope of what I am working on.
Easy- so you put the non pdf files in package of files in the DDX which will be added as attachments
Hi @jCaltrans ,
what you want to do is perfectly possible, we do not automatically convert non-PDF to PDF if not told to do so.
The use case as I understand it:
Is that the correct description?
Can you post the DDX that you apply with the Invoke DDX step here so we can have a look.
Kosta
Yes to the steps with the exception of using the generatePDFOutput object so that the dynamic PDF has its state preserved.
Here is the DDX generated from script using the list generated from extracting the attachments:
<?xml version="1.0" encoding="UTF-8"?>
<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
<PDF result="outDoc">
<FileAttachments source="0">
<File filename="testattach.docx" mimetype="application/vnd.openxmlformats-officedocument.wordprocessingml.document"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<FileAttachments source="1">
<File filename="exceltest.xls" mimetype="application/excel"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<FileAttachments source="2">
<File filename="attachTest.txt" mimetype="text/plain"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<PDF source="3"/>
</PDF>
</DDX>
Hi @jCaltrans
the DDX per se is ok, you would not even need the mimetype. I used a static PDF and added an xlxs file and it showed up allright.
I have a feeling that your extraction of those attachments already goes wrong.
I did a quick DDX only approach which extracts and adds. The file types remain what they were.
<DDX xmlns="http://ns.adobe.com/DDX/1.0/">
<FileAttachments result="attachmentInfo.xml" nameKeys="*" extract="true">
<PDF source="doc3.pdf"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<PDF result="outDoc">
<FileAttachments source="doc3.pdf_attach.0000.0001">
<File filename="testattach.xlsx"/>
<FilenameEncoding encoding="UTF-8"/>
</FileAttachments>
<PDF source="3"/>
</PDF>
</DDX>
This pulls attachments from an XFA PDF and then I can use it to add to a static PDF.
The naming of the attachments source is generic. When you generate your DDX you can dynamically set it.
Please refer to the sample PDF[0] in which JavaScript has been used to add multiple attachments of different types. The PDF file needs to be reader extended to work in Acrobat DC Reader.
[0]: https://drive.google.com/file/d/1j2aK65Mk7eF_Bi2PoHf9CWc4ir5c58we/view?usp=sharing
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies