Ok, I thought your problem was that the header neded to change based on what happened in the main report. pdfCreatePagesGroup is the way to go if that's the case.

If your header data is static it's much easier. Do you have the data in the dataset you provide for rendering the report? Just access it from your header-report like Jan described above in this thread.

If you don't have the data in your original dataset, you might want to fetch it from a remote place. The fetch would be easies to to in onBeforeRender. When you have the data you can add it to req.data.whatever and then reach it from your header-report as {{@root.whatever}}

If I understand correctly I have the same need, and a solution.

1. I have a separate header-footer report which I merge with PDF-utils
2. I'm "sending" data to the header-footer report via $pdf.pages, i.e. by calling {{{pdfCreatePagesGroup}}}
3. The header-footer report simply iterates $pdf.pages

Iterating $pdf.pages in the header-footer report. All pages but the first (1=0) gets a pageBreak:

        {{#each $pdf.pages}}
            {{#if 1}}
                <div style="page-break-before: always;"></div>
            {{/if}}

            <main class="main">
                <header class="top">
                    {{#if group.bannerColor}}
                        <div class="top-banner" style="background-color: {{group.bannerColor}}; color: {{group.textColor}};">

...etc

Here is an example calling pdfCreatePagesGroup in my main report:

{{{pdfCreatePagesGroup bannerColor=(getLevelColor @root.controlpointLevelColors levelId 'report') 
   textColor=(getLevelColor @root.controlpointLevelColors levelId 'text') 
   title=(getLevelTitle @root.report.properties.mainControlpointTypeId levelId) 
   subtitle=(getControlpointIdentifierLong ./this) 
   infoText1=../name  
   infoText2=../images.[0].name 
   showAddress=true
}}}

Today I got a message from a SaaS company which I use for book keeping. They said that they had problems creating reports due to the last Chrome version.

I reached out to their developers to get more insight. They said that they had found the problem and had a dialogue with Google, hoping for a patch soon.

If this is the same problem it might be fixed soon. I'll report back here when I know more.

After upgrading from 4.3.1 to 4.4.0 my cover page report crashes. One main difference from other reports is that the cover page has zero margins, both vertically and horizontally.

To ensure that this is just a version difference I have rebuilt my local docker image and re-rendered the report. The only difference between the two builds is the version number in the Dockerfile.

Occationally I can render the report on 4.4.0, but it mostly crashes.

As of now I cannot move to 4.4.0.

This is how the report should look. Has been working fine from v2 to v4.3.1


After upgrading to 4.4.0 and running the exact same report I'm getting this:

Page crashed!
Error: Page crashed!
    at #onTargetCrashed (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Page.js:403:50)
    at /app/node_modules/puppeteer-core/lib/cjs/third_party/mitt/mitt.js:62:7
    at Array.map ()
    at Object.emit (/app/node_modules/puppeteer-core/lib/cjs/third_party/mitt/mitt.js:61:20)
    at CdpCDPSession.emit (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/common/EventEmitter.js:83:23)
    at CdpCDPSession._onMessage (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/CDPSession.js:82:18)
    at Connection.onMessage (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Connection.js:141:25)
    at Immediate. (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/node/NodeWebSocketTransport.js:43:36)
    at process.processImmediate (node:internal/timers:476:21)

Here is a screenshot of the console logs just before the crash:


I haven't had time to investigate this, but I actually have been seeing more server crashes due to low memory lately. I'm rendering some huge reports, so I thought I had some bugs or something. I'll be following this thread if anything comes up that I should test.

Last week my JSReport 4.3 docker container at Fargate restarted two times due to low memory, which is quite rare.

I'm regularly generating reports from JSON which is 100,000 - 200,000 lines (formatted json), i.e. 20-40MB. These reports takes time to generate (sometimes many minutes), but the input size is not a problem.

Is it possible to reuse resources multiple times inside of a PDF in order to not bloat the PDF with multiple copies of the same image? Also, I need this to work within SVG tags because I'm overlaying the images with svg graphics.

My use case:

1. Show one large original image on one page
2. Show multiple different crops (viewbox) of the same image inside of svg elements on other pages

Here are some idéas that I don't think will fly:

1. define the image as an svg resource with <defs> and use it multiple times with <use>. I need many separate svg tags and defs is only scoped to the current svg parent, so this won't work.

2. load the image as a background image defined in a css class. The background image concept does not seem to work for images inside of svgs.

Any other suggestions?

My fallback solution will be to have a server generate all the croped jpg images to minimize the size. Viewbox only hides parts of the image, but the complete image is still stored in the pdf multiple times.

This might be completely unrelated, but I gained much in performance when I migrated from child reports in 2.11 to components in v3.

Most of the gain was due to my misuse of child reports. In my calls to the child reports I added data, sometimes quite a lot of data. I didn't realise that the calls to child reports would copy all the data. This was very taxing on the memory on my server, especially when multiple large reports were rendered.

Even if you are not misusing child reports, as I did, I think components are a much nicer concept.

Jan, what do you mean by "disabling the ARIA"? Where can I do this?

I'll answer my last question here as well, so the topic gets completely solved.

"Should I make some extra call lastly in afterRender to make the final cleanup of the hidden marks?"

• This can be done by calling pdfUtils.postprocess as per the docs (https://jsreport.net/learn/pdf-utils#-postprocess-sourcepdfbuf-pdfmeta-pdfpassword-pdfsign-outlines-)

Almost solved..

Because I'm appending manually with jsreport.pdfUtils.append in afterRender, I also needed to call postprocess. The href now works, but the PDF outline still links to the TOC instead of page 10.

I guess I can fix this somehow with postprocess as well, since I can add outlines to this call.

Could anyone link me to an example on how to repair links in the outline after rendering and appending.