-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pdf.toStream() ? Issues with larger pdfs #46
Comments
Hi, thanks for reporting your issue! Regarding I'll try to trigger the same error first so that I may not need your source data. Are you using version |
Are you saving the pdf with encoding set to fs.writeFile(fileName, pdfString, 'binary', function () {
console.log('saved');
}); Edit: I think I am not able to reproduce you issue. Are you getting the location of where in your PDF the issue occurs? If so you could also give me the some lines surrounding this location straight out of the .pdf file. Thanks |
Yes, I'm using that version, and yes, I've been saving the file as binary. I think if you create enough data you'll be able to recreate. Thanks for On Saturday, October 10, 2015, Markus Ast notifications@github.com wrote:
|
Are you just adding text, or also images? |
Just text. Here is the code that I use to create each document:
And here is some sample code that populates my doc metadata:
I don't have any sample data for pages, but they would have the format:
where the data object would have the same format as headerRowsData in the metadata object. The values within the data object would be numbers. |
I've created a full test gist here: |
Should be fixed in There are some more possible ways to reduce file size, e.g.: draw borders for each row and not for each single cell and compress PDF content streams. I've added these features to my todo list, but they do not have a high priority. For performance and memory usage: I'll definitely add a streaming API. But unfortunately, not before December. Thank you very much for providing the example code! |
Awesome improvement! Besides fixing the invalid character issue, the 28-page report shrunk almost in half - from 6 Mb to 3.3 Mb. The streaming API would be amazing, and yes, definitely something that will take some time. Unless you want this issue kept open to keep track of the streaming API, I will close it. |
I am glad it worked out! Streaming API will be tracked in #47 |
Version |
I think I'm running into memory issues when rendering larger pdfs.
Right now I'm creating 3 similar pdf files. The page on each pdf contains a table with 25 columns and anywhere from 4 to 25 rows.
2 of the 3 pdf files work fine, because at most they produce 3 pages each. But the 3rd pdf is big. It is 6 Mb size, and has 28 pages in it. Pages 19-28 cannot be viewed in Adobe Reader (but they can be viewed in Mac Preview.)
I've tested the big pdf at "http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx", PDF/A-1b, which gives me the following error:
The content stream contains an invalid operator. (10)
It says the error occurred 10 times, which makes sense since pages 19-28 cannot be viewed.
Now, if I render the same document, but only render pages 19-28, they render just fine. So there must be some resource limitation that is causing the issue.
I've tried rendering the pdf on different machines, and each machine produces the same result.
Instead of using pdf.toString() to trigger the building of the pdf, I'm wondering if creating a text stream from the pdf via a method like pdf.toStream() would prevent the resource limitation. Is this even possible to do with the code? I'm going to fork the code and try it, but if you think this is all but impossible, please let me know.
I cannot share the json data used to render the pdf, since it has client info. If you think it would really help to have this data in order to debug the issue, let me know and I'll try to obfuscate the data.
The text was updated successfully, but these errors were encountered: