Topics created by msageryd

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?

Of course, I should have thought of that.
Thank you for explaining.