Hi! @bjrmatos,
Following up on the issue I shared earlier. Just wanted to check if you had a chance to look into it.
Appreciate your help!

Hi @bjrmatos,

Here's a simple template to reproduce the issue: https://playground.jsreport.net/w/anon/_x2Y2DRG

The expected behavior is that each chapter appears on a separate page, which works correctly in jsReport v4.9 and earlier versions.

However, starting from jsReport v4.10.0, section breaks are ignored, causing all chapters to be rendered on a single page.

Hi @bjrmatos

Could you let me know where I can find more details about the changes related to the section break? I'm asking because we encountered the opposite situation: our template works correctly with JSReport v4.9, but all later versions produce incorrect results when conditionally rendering a section break.

Hi everyone,

After upgrading JSReport from version 4.7 to 4.8, we encountered an issue with table borders when using the html-to-xlsx recipe. Here's a minimal reproducible example: https://playground.jsreport.net/w/andribo/_CUkL33T. It works correctly in the playground because it runs on JSReport 4.7.

The issue may be related to how the recipe handles cells with the colspan attribute.

Here's the result when using the html recipe:

Here’s the output of the html-to-xlsx recipe in version 4.7:

However, in version 4.8, the result looks like this:

As you can see, some table borders are missing in the output.

@bjrmatos, @admin,

Thank you, guys! The ability to provide a custom loader function fully meets our needs and resolves the OOM issues we were facing.

Hi Jan, thanks for creating a ticket for that! I noticed that the same issue is occurring in the docxHtml helper - would you be able to look into improving image loading there as well?

Also, do you have an estimated timeframe for when this might be picked up?

Hello,

We are implementing a Word report using the docx recipe and encountered issues when inserting multiple images into the report.

Issue Description
To include images, we use the docxImage helper, providing the src as a base64 data URL. In the beforeRender script, images are prefetched to handle authentication properly and then passed to docxImage.

However, this approach leads to high memory consumption, often resulting in an Out of Memory (OOM) error when processing larger images or multiple images at once.

At the same time, when images are provided as direct URLs - allowing docxImage to handle the loading - everything works fine.

Reproduction
We have created a minimal example to reproduce the issue: https://playground.jsreport.net/w/anon/CVpIkxye (See README for details).

Possible Cause & Suggested Solution
From what I see, axios is responsible for loading images inside the docxImage helper, specifically in this line:
https://github.com/jsreport/jsreport/blob/master/packages/jsreport-docx/lib/imageUtils.js#L32

We would like to know if there’s a way to provide custom options to this axios request. In our case, we need to:

• Set an Authorization header for authenticated requests

• Adjust httpsAgent settings to support self-signed certificates

I initially tried setting axios defaults within the report script, but I suspect that docxImage and report scripts run in separate contexts, so this approach didn't work.

Request for Support
Is there a recommended way to handle this? Any advice on working around the OOM issue or configuring axios inside docxImage would be greatly appreciated.

Thanks in advance!

Thank you, @bjrmatos!

It turns out passing a promise was an unintentional mistake, though fortunately, it didn’t cause any issues. :)

In our setup, we prefetch images in the beforeRender script, convert them into base64 data URIs, and pass these images to the data. Recently, we introduced an asynchronous image resizer into this process but didn’t handle its output correctly.

Since you mentioned that using a promise with a URL as the "src" is expected behavior, I think we can keep our current implementation as is.

I do have one additional question: when adding promise-based properties to the template’s "data", are there any limitations on what can be passed? Specifically, does the data need to be JSON-serializable, or can it include any JavaScript variable?

Hello,

According to the documentation, the "src" property of the docxImage must be "the base64 dataURI string representation of the image to load or an url from which to fetch the image".

However, it turns out, that it can also be a promise fulfilled with the base64 data URI string. I suppose this is due to using the waitForAsyncHelper inside the docxImage.

Would it be reasonable to rely on this feature of the 'src' property, or is it better to strictly follow the documentation and provide a string value?

That's a shame ((
Thanks, @jan_blaha for a reply.