Topics created by msageryd

If anyone is interested, or encounters the same problem.

Topping out the CPU is really bad. When it reaches the top, the current report rendering seems to slow down to almost stand-still. I was contemplating setting up a second JSReport server, but that would not have solved our type of load. We have very few renderings (10-20 per day), but sometimes really big reports are rendered. The most important bottleneck in our setup seems to be topping out the CPUs.

The left part of this chart shows three attempts to render a very large report. Each of the attempts timed out after 10 minutes.

To the right in the chart, the same report is rendered two times after upgrading from 2 vCPU to 4 vCPU. Each render took about 40-42 seconds.

The last cpu bump is a smaller report. This particular report was actually rendered successfully with 2 vCPUs a couple of days ago, so I had metrics to compare. With 2vCPUs the smaller report took 14 seconds to render. After the upgrade, the same report took 9 seconds. This is a reasonable performance bump, but its always nice with confirmation.

Update:
I got window.JSREPORT_READY_TO_START to work by ckecking "wait for printing trigger", but the measurement are still taken before automatic page breaks.

I have tried both setTimeout and requestAnimationFrame. Is there no way to await chrome-pdf's automatic page breaking before taking measurements?

Don't you have the pdf/a or pdf/ua enabled in the pdf utils options?

I have no theory why would the pdf utils could break it otherwise. Maybe you can create minimal exprt so we can check it.

Replacing the server.js makes the most sense to me.

You need to set license.development=true if you have the single instance license and want to use the local instance as dev free.

Never mind.
I see that the message is truncated at 1000 characters. This is probably reasonable to not bloat the logs.

I solved it by chunking my console.log calls instead.

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.

I apologize for the delay.
There were some issues I had to fix, but with the next version of jsreport, you should be able to get the outlines cross-templates working in the script better.
So this should work in the next update
https://playground.jsreport.net/w/anon/7ysL9rwu

It seems that at this moment you can also call postprocess twice as workaround

res.content = await jsreport.pdfUtils.postprocess(res.content, {}) res.content = await jsreport.pdfUtils.postprocess(res.content, { outlines: [{ id: 'a1', title: 'link to another template' }] })

If you want to test the current jsreport master, you can do git clone on https://github.com/jsreport/jsreport
and yarn install && yarn start.

We plan to release this week likely.

I solved this by adding this global helper:

function getRoot() { return jsreport.req.data; }

Is this an ok solution, or should I do it any other way?

So, instead of trying to calculate the offset and try to marchal the data to req (which I think is really hard due to the isolation between the browser and Node), I opted for the "render twice" concept as per: https://playground.jsreport.net/w/admin/tV6sVKbV

This is a really neat solution for complex TOC layouts. The drawback is that the complete report has to be rendered twice. I will try to optimize this by rendering empty placeholder divs where I have complex components (such as graphs and complex SVG) and their height is known. Placeholders will only be used in the first render.

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-)

Great that you made it work with components!

The thing about cheerio is that by design they dont have access to calculated dimensions like outer width, but long time since i checked its api so i could be wrong

The docxtemplater recipe was our initial "quick win" to support docx format by wrapping already existing library docxtemplater. This was always shipped just as a custom extension.

In time we realize we can do better by implementing our own docx engine using handlebars and all the features we already have in jsreport - assets, localization, components... This was shipped as docx recipe. This recipe soon became the main part of the jsreport with pptx recipe and xlsx recipe which uses the same approach - typing handlebars inside the office app.

The docx is now one of the main assets of jsreport and has the similiar popularity as pdf rendering promising long life and main support.

So you should use the new office recipes docx, pptx and xlsx which are part of the default installation.

Is the following true?
If no data is supplied to jsreport.render, jsreport will autmatically use res.data.

yes, right now it works like that. in terms of the data the render that originates from proxy automatically inherits the data of the current render

@msageryd yes, for the Apple Silicon hardware there are special steps (options and params for docker), it is described here. i guess it can help you too (personally, i do all my development on macos with Apple Silicon hardware so i was on charge of writing those instructions)

Does anyone know if there are ARM containers available at AWS Fargate?

i am not aware if there are ARM containers there, so i am afraid i won't be much help on this point

Do you mean that enabling pdf-a in V3 would solve the color problem?

No. It just removes some transparency things to make the output compatible with pdf archive standard. So that won't help

I discovered the problem on our old production server with jsreport 2.11.

I see, v2 doesn't do anything with the colors. It's the output from chrome. I've never noticed this problem. Try to isolate the problem. Put just the image to a template, does it produce bad output? Try it locally. The same?

Thanks again.
Maybe some of this should be added to the asstes docs (https://jsreport.net/learn/assets#wrap).

This would have helped me:

Assets loads faster than components, but must be static Assets cannot be nested If the content is not static, use components

Thank you for a speedy saturday-answer.
Have a nice weekend.

That's great!
I was looking for an API like this, figured it should exists somewhere.

Is there any documentation for tha jsreport-APIs?