This is the first time you are trying to reach us, as far as I see, and it is one hour back.
Unfortunately, we don't have enough resources to provide 24/7 phone support, I apologize for that.
We'll do our best to help.
You are using a wrong email to reset the password, I email you the right one and check what is the error you provided about.
Our server hosting temporary office documents for preview has some input limits and you are reaching them.
Please use the "Download" button in the studio instead of run.
This won't try to upload the document to the public server and shouldn't fail.
Or check how to disable the preview here https://jsreport.net/learn/office-preview
Understood. I agree regarding your previous statement. The "render" method is not blocking the app given the "promise" implementation. However, it's still an issue for us.
We use heroku to deploy our application. Unfortunately, heroku implements a hard 30sec request timeout. This means that any request by our client to render a report from jsreports must complete in 30sec or less. If it does NOT, then the heroku web server terminates the request and returns an error to the client. We have some reports that are getting close to reaching that limit and we'd like to implement some sort of polling architecture before it becomes an issue.
I'd not tried using the docx as a linked asset, that would certainly save me a few steps as I experiment!
If my current use-case of a table with variable rows supportable, or should I drop in a feature request to github for that?
I guess I'll have to handle the file logistics anyway. I'll venture into the following:
enlist all SVGs and images needed in the email
render each SVG separately with a chrome-image recipe and save the images at s3
render the html-email with links to the saved files
I'd rather not have to do the above, but it seems that I have no choice if I want my emails to be readable in various mail clients. One upside is that I can probably solve the resolution and object-fit when I have an actual image to work with (compared to a an embedded base64 image).
what would life be without interesting quirks :)
knowing the code workaround is good, and both the proposed solutions make sense (adding the options in v2 defaulting to false would surface the solution, and then in v3 flipping the default for new templates - especially surfaced with the checkbox in Studio - would avoid confusing people with the change)
tried some small changes (but really need the reports to fit close to 'regular' A4 margins so don't have much wiggle room), and still getting the issue (not on every page, but see it appear both as an extra line at the bottom and a double weight line between the thead/tbody area on different pages.) - looks like this is another issue that should get addressed with the LayoutNG fixed in Chromium so hopefully that's not going to be too far away...