3. Large PDF Generation

Large PDF Generation

  • S

    Hi,

    I'd like to know how large the document can handle for the PDF generation. Is it possible to generate a PDF with book level pages like 900-1000 pages?

    Thanks,

    0

  • There is no specific limit for the number of pages. I have seen reports with many thousands of pages.

    However, the rendering time may increase significantly with complex graphics like charts.
    Its recommended to design one page, multiple it to thousands, and test the performance.

    0
  • S

    Hi, there's an error message shown as below when I was trying to generate a PDF with around 1500 pages, with a pdf utils configuration that merges single/multiple separate template(s):

    Error: Cannot create a string longer than 0x1fffffe8 characters
    at Object.slice (node:buffer:641:37)
    at Buffer.toString (node:buffer:791:14)
    at AsyncFunction.<anonymous>

    I'd like to ask if it's possible to generate a PDF with many thousands of pages with the pdf-utils merge operation being configured? If so, how could I solve the mentioned error above?

    Thanks.

    0

  • @sjyeap Would you be able to replicate the issue for us? By providing the entities export and input data.

    0
  • S

    @jan_blaha Thank you for your reply. Please find the exported zipped file in this google link: https://drive.google.com/drive/folders/1xajuZRw9XfFcBzNg84u0TEMWZW2rcm9f?usp=sharing

    *PS: Today I restarted the server and tried to run the same program again. It worked for the first few times but after several attempts, the error repeats again.

    0

  • Thank you for the export.

    pdf utils extension have issues with 600mb pdf you produce. I believe this will get solved in the jsreport v3 where we implement a much more optimized technique for communicating between worker processes. However, you will need to wait some months before this is released.

    The reason for 600mb pdf is your images. You use CSS style to reduce the image size to 300x300, but the pdf includes still the original size 650x940. To solve this, you can change the URL of your images from ?auto=compress&cs=tinysrgb&h=650&w=940 to ?auto=compress&cs=tinysrgb&h=300&w=300. You should see no errors afterwards.

    0
  • S

    Thank you very much for the reply. In over 90% of the situation we won't be hitting this size of report. We try to disable the toC but seems it can't help much in this situation. Is there a way for us to increase the memory allowed in the pdf utils process?

    0

  • We transfer the big pdf buffer with base64 encoding and nodejs has a limit for max string size. I am afraid the memory increase won't help likely.

    As I mentioned earlier, the solution with embedding images with proper size should work for you. Doesn't it?

    0
  • S

    This is the sample project we are working on. We try to evaluate the capability of the tools and performance. Currently, we have requirement on the image clarity for the printed document to indicate defect location. As the number of defects can vary based on project size, it looks like we could encounter such an issue for a large project anyway.

    0
  • S

    @jan_blaha Thank you for the reply! It works perfectly fine after changing the size of images to 300x300.

    However, in our project we're actually considering to generate pdf files larger than 600mb. May I ask, can this issue be solved in jsreport v3? If yes, may I know approximately how many more months do I have to wait until it is released? Thanks.

    0

  • Maybe you can also skip the TOC for now? You mentioned it didn't help? Try to disable the pdf utils extension fully.

    { "extensions": { "pdf-utils": { "enabled": false } } }

    It can be solved in v3, it is my expectation. We are still far away from some guessing of dates. Maybe a mid year.

    0
  • A

    Hi, I would like to check again if version 3 address this problem. If it is, I will arrange a test on that.

    0
  • S

    I am retesting this on jsreport v3. I encounter the following. But from the error message, its quite difficult to identify the area which goes wrong.

    2022-04-10T09:20:21.825Z - warn: Error when processing render request 6 Error when evaluating engine handlebars for template /elevator/cover
    2022-04-10T09:20:21.825583200Z Invalid string length RangeError: Invalid string length
    2022-04-10T09:20:21.825623900Z at String.replace (<anonymous>)
    2022-04-10T09:20:21.825648200Z at executionFn (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:139:39) rootId=32lk7nj9sy8tpre, id=pfjx2hcpag1tcxk
    2022-04-10T09:20:21.826557400Z 2022-04-10T09:20:21.826Z - warn: Rendering request 6 finished with error in 294407 ms rootId=32lk7nj9sy8tpre, id=pfjx2hcpag1tcxk
    2022-04-10T09:20:21.831042900Z 2022-04-10T09:20:21.830Z - warn: Error when processing render request 2 Error while executing pdf-utils operations. Error when evaluating engine handlebars for template /elevator/cover
    2022-04-10T09:20:21.831105400Z Invalid string length Error: Error while executing pdf-utils operations. Error when evaluating engine handlebars for template /elevator/cover
    2022-04-10T09:20:21.831126900Z Invalid string length
    2022-04-10T09:20:21.831150000Z at module.exports (/app/node_modules/@jsreport/jsreport-core/lib/shared/createError.js:10:13)
    2022-04-10T09:20:21.831172800Z at WorkerReporter.createError (/app/node_modules/@jsreport/jsreport-core/lib/shared/reporter.js:47:12)
    2022-04-10T09:20:21.831195200Z at AsyncFunction.<anonymous> (/app/node_modules/@jsreport/jsreport-pdf-utils/lib/worker.js:191:22)
    2022-04-10T09:20:21.831215000Z at async ListenerCollection.fire (/app/node_modules/@jsreport/jsreport-core/lib/shared/listenerCollection.js:157:21)
    2022-04-10T09:20:21.831235300Z at async afterRender (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/render.js:104:5)
    2022-04-10T09:20:21.831257600Z at async WorkerReporter._render (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/render.js:152:7)
    2022-04-10T09:20:21.831279500Z at async /app/node_modules/@jsreport/jsreport-core/lib/worker/reporter.js:177:19
    2022-04-10T09:20:21.831313900Z at async Domain.<anonymous> (/app/node_modules/@jsreport/advanced-workers/lib/workerHandler.js:141:19)
    2022-04-10T09:20:21.831335900Z caused by: RangeError: Invalid string length
    2022-04-10T09:20:21.831358400Z at String.replace (<anonymous>)
    2022-04-10T09:20:21.831378900Z at executionFn (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:139:39) rootId=32lk7nj9sy8tpre, id=32lk7nj9sy8tpre
    2022-04-10T09:20:21.832673200Z

    0
  • S

    It looks like this is due to the handlebar template too large. I changed from dataURI to Url to fetch the images.
    and the error change to pdf utilsError while executing pdf-utils operations. Cannot create a string longer than 0x1fffffe8 characters
    Error: Error while executing pdf-utils operations. Cannot create a string longer than 0x1fffffe8 characters
    at module.exports (/app/node_modules/@jsreport/jsreport-core/lib/shared/createError.js:10:13)
    at WorkerReporter.createError (/app/node_modules/@jsreport/jsreport-core/lib/shared/reporter.js:47:12)
    at AsyncFunction.<anonymous> (/app/node_modules/@jsreport/jsreport-pdf-utils/lib/worker.js:191:22)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async ListenerCollection.fire (/app/node_modules/@jsreport/jsreport-core/lib/shared/listenerCollection.js:157:21)
    at async afterRender (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/render.js:104:5)

    0
  • S

    After further check, this issue only happen when using the run and profile. If I change the mode to Run only, the issue disappeared. Currently I am ok to generate file at 1GB referring image by URL.

    0

  • @silvercrux-afk

    Thank you for checking!

    It looks like this is due to the handlebar template too large. I changed from dataURI to Url to fetch the images.

    Yes, this is the correct solution.
    We have in our backlog a task to make the big strings work with handlebars as well, but the better option is to use images from URLs in such amount. If you have that option....
    https://github.com/jsreport/jsreport/issues/839

    After further check, this issue only happen when using the run and profile.

    When running with full profiling, whole outputs of individual operations are persisted in base64 so it fails for giant pdfs. I submitted to the backlog task to skip it in such case to provide better user experience.
    https://github.com/jsreport/jsreport/issues/905

    0
Log in to reply
 

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.