I am trying generate several individual pdfs from html in a group of elements within a node on a webpage with jsPDF. (Report cards for students). Then I need to email the individual report cards to each students parent using JavaMail.
The problem is: I don't want to save the pdf files to disk as they are generated, instead I want to programmatically loop through the report card elements in the page (id="'studentCard_' + studentId", generate the individual pdfs from the html and store or push each individual pdf into an array or object on the fly (as they are created) that I can then pass over to JavaMail and loop through to attach each individual pdf to the associated parents email.
I can convert the html to pdf without a hitch...
I am just not sure as to how to then attach this pdf to the email since the only option is to pdf.save(filename), and I don't want to actually SAVE each individually generated pdf in the loop to disk - I just want to temporarily store the generated file before I attach it to the emails and send it out.
I have converted the pdf to a blob and a blob URL and I am able to then push the blob into an array. Can I just convert the pdf to a blob or blob url and push it to an array and then loop through that array and attach that to the email. Is this my Solution to convert each pdf to a blob, then push the blob to an array to be passed on to JavaMail to loop through?
I don't know anything about this aspect of my problem. If I attach a blob to the email, or insert the blob URL in the body, when the parent clicks on the file to download it, or clicks on the link inserted into the body, will it automatically be converted back to PDF format for them to read by their own mail program or in the browser? How do I do this correctly?
You may use IndexedDB, the client-side storage of the browser. I like JsStore, an IndexedDB wrapper. I have used it for a couple of my projects. It's pretty neat.
pdf.save(filename) is NOT the only option. You should be able to use pdf.output(datauristring) or pdf.output('blob') and save it to IndexedDB. Depends on your pdf file size, you may even use localStorage, which is easier to use but has much less storage than idb.
Related
I have a folder of PDF files, what I want to do is build a small app with directional arrows that when pressed should upload the next PDF file from the uploaded/Selected folder.
I have tried uploading single PDF and I was able to view it, but I'm unable to find any good resource on how to upload a whole directory inside the application for me to not upload each PDF every single time.
I should be able to change my current opened PDF to the next one inside the folder.
The way to do this in Vue is as follows:
Make a input field and attach the event "v-on:input" with the function that will be called when the input is selected.
Don't forget to add "webkitdirectory mozdirectory" for firefox and chrome browsers.
Inside the function fetch the input query via "document.querySelectorAll('input');". The information of files will be inside files object.
If I apply a digital signature on a PDF file which contains another PDF files attached on it, does the signature apply to the whole document including attachments, or only to the "main" PDF ?
The goal is to detect any modification on any part of the document itself and all the files attached.
The signature on the parent document will calculate it's checksum based on all the bytes in the file. If any of the attachments are modified and saved back to the parent file, you will be able to detect that the entire package has changed but unless you also sign the child documents, you may not be able to tell which of the children was changed.
You may also want to invest in a certificate that is already on the Adobe Approved Trust List so that the document will appear valid when first opened and the use won't need to install your specific certificate. You can read more about this at the URL below.
http://helpx.adobe.com/acrobat/kb/approved-trust-list2.html
Assume, you have a PDF with attached files. From the point of view of PDF structure and PDF syntax, these attachments are represented by embedding some "standard" PDF objects including "streams".
When you digitally sign this PDF file, the signature is valid for the complete PDF file, consisting of all PDF objects (thusly including the attachments).
Should someone extract a copy of the attached files, modify them and then re-attach these, it will change the contents of the PDF. Hence the signature will become invalid by this change, which leads to the detection of the modification.
What you cannot detect:
if a copy of the attachment has been extracted (leaving the original PDF un-modified)
I have an application, which has pdf attachment inside documents. Need to edit the pdf meta data and append or add document information(some field values from document) into that pdf.
I want to add the values into meta data so that when pdf is printed these values should not be seen. If we go to File Properties of any pdf we can find Author and other information, it should similarly show field values which I want to insert.
All above functionality has to be done using Lotus Notes, might be any tool can help.
I am using CutePDF SDK in one of my recent project to manipulate PDF files. You install a COM object on the system (cclient or server) where the code is executing, then you can update meta data like author, etc. Even password protect the file if you like.
You can download a demo version here: http://www.cutepdf.com/solutions/formsdk.asp
In your case, you must detatch the PDF file first, the perform the changes and then reattach it to the Notes document.
If Java is an option you can try iText. http://itextpdf.com/
We use that to generate PDF's from Lotus.
I have a Domino database that stores documents with file attachments. The file attachments are stored in the Body RichTextItem as attachments.
For managing these documents I have an HTML form containing a file upload field.
Now, when I upload a file whose name differs from the current file in the document, everything works fine, and the uploaded attachment replaces the previous attachment.
The problem is when I upload a file that has the same name as the already existing file. In the WebQuerySave property of the form I call a LotusScript agent that should replace the old attachment with the one from the HTML form.
But in this agent I see two items called $FILE that have the same FileName. When I access them, I cannot distinguish these two items. I tried:
document.GetAttachment(filename) – obviously doesn't work, since the names are the same => I can only access the first attachment.
ForAll item in document.Items – I visit two items having the name $FILE, but both items are the same: the modification time is the same, the filesize is the same.
I could get all the attachments and remove all of them but the last. But is there any guarantee that the last item is the one from the HTML form? Or I could first extract the modification time from all the attachments and remember the newest. That must be the attachment from the HTML form.
Or is there a simpler solution?
For reasons like this behavior and several others, I have built most of the basic web facing Domino applications to store attachments on linked documents instead of the primary document. That way they can be accessed easily and do not get updated or modified except when they are supposed to be.
Situation:
(Large) PDFs are stored on an iOS device
The PDFs are encrypted using a Rijndahl algorithm
When tapping one of the PDFs, it gets decrypted and afterwards viewed using a PDF viewer I implemented. The viewer is using the Core Graphics functionality to render the document page by page.
Issue:
With the documents being large enough, encrytion will take a while.
Viewing can only be started after the whole document has been decrypted into a temp file.
I'm wondering, if there is a way to...
Pass some kind of stream to CGPDFDocument instead of a file URL
Or any other alternative to be able to view as many pages as possible whil decrpytion is continued in the background?
If you cannot split your original PDF files down to single pages (as I suspect), then the following approach should work:
A: When still decrypting:
try to open the PDF document as you already do;
try accessing the document page you are interested in;
if it does not fail, render the page;
if it fails, then you know that page is not available yet (while decrypting);
while decrypting, release the pdf document each time you try to get a new page.
B: when decryption is done: do as you are already doing.
Please note that this is just a suggestion, I have not tried this while decrypting a document, but if point 1. does not fail, then this should work.