Posts made by JannetGen

I’ve been looking into this as well. While using the pdf-utils and adjusting the pdfSettings in the configuration is the standard way to handle it within jsreport, sometimes the compression isn't as aggressive as I need for certain documents.
If you're just looking for a quick way to shrink a file down before sending it off and don't want to mess with the server-side code right now, I've found this tool pretty handy- https://www.thetoolapp.com/compress-pdf-file/. It’s been a life-saver for me when I'm in a rush.
Curious to see if anyone else has managed to get significantly smaller file sizes just by tweaking the internal jsreport chrome-pdf settings though!

If you’re looking to do this programmatically within jsreport, the script approach mentioned earlier is definitely the way to go for automation.
However, if you just need a quick way to split a specific file manually without messing with the code right now, I’ve used https://thetoolapp.com/utilities/split-files/ before. It’s pretty straightforward for splitting things page-by-page.

I’ve run into similar issues with field mapping in the past. If you're looking for a quick way to test the form structure or just need a straightforward way to see how the fields behave before automating the whole thing, I sometimes use this simple tool- https://thetoolapp.com/pdf-tools/fill-pdf-form/. It’s pretty handy for verifying the PDF side of things while you're debugging your jsreport script.

That’s a classic challenge with Word-based reporting. Usually, when images aren't showing up in the footer, it’s because the docxImage helper is struggling with the specific scope of the footer part in the XML.
One thing that often helps is making sure the image data is already fully resolved in your data object before the rendering starts. Also, double-check that you're using a relatively small image file - sometimes the footer container in Word is a bit more sensitive to large base64 strings than the main body is. If you've already tried that, sometimes wrapping the image in a fixed-size table cell in the footer can help "force" the rendering engine to reserve the space properly!

If you are using the chrome-pdf recipe, the easiest way is usually to use the native 'Header' and 'Footer' templates in the jsreport studio. Anything you put in that header template section will automatically repeat on every page. Just make sure you leave enough margin in your main template so the header doesn't overlap with your content!

I’ve noticed that when jsreport starts lagging, it’s usually either a massive data object being passed to the template or Chrome's memory management hitting a wall.
One thing that really helped me was switching to the headless Chrome launch strategy in the config, or making sure I wasn't doing heavy data processing inside the Helpers - doing that before passing it to the engine makes a huge difference. Also, if you're using a lot of images or heavy CSS, try checking the "Scripts" execution time in the profiler; sometimes a single synchronous loop in a helper can hang the whole render.

I’ve run into similar styling issues with docx templates before. Word can be really picky about how it interprets background colors compared to a standard browser. Sometimes the docxStyle doesn't apply correctly if there's conflicting 'shading' settings already in the Word document itself. It might be worth checking if the base table or cell in your .docx file has a default fill color set to 'None' or 'No Color' instead of being completely unstyled.

That’s a strange one. I’ve seen similar issues with imports before where the core data moves over fine, but the metadata or link tables for permissions don’t seem to 'hook' correctly in the new environment.
Have you checked if the Group IDs in your export file actually match the IDs in the new instance? Sometimes if the groups aren't created in the exact same order or if they have different internal IDs, the permissions end up pointing to nothing. It might also be worth doing a quick check of the logs during the import to see if there are any 'foreign key' or 'unauthorized' errors popping up silently.

That sounds like a permissions sync issue. Since you're working with the API to elevate rights, have you checked if the changes require a fresh session or a manual cache clear on the jsreport side?
Sometimes the internal store doesn't reflect the new role immediately via the UI even if the API call returns a success. It might be worth trying to re-authenticate the user after the call to see if the admin privileges kick in properly.

That’s a frustrating one, especially when it seems like the footer calculation is just slightly off. Have you tried wrapping the footer content in a fixed-height container or adjusting the marginTop and marginBottom in your Chrome-PDF recipe?
Sometimes Chrome’s rendering engine gets a bit confused with page-break logic if the footer content is too close to the edge. Shrinking the footer font or slightly increasing the bottom margin usually clears up those weird overflows.

The startup script idea mentioned here is probably your best bet for a stateless setup. You could essentially pack your user creation logic into a small script and run it via an initContainer or a post-start hook in your K8s deployment.
Another way to handle it without persistence is to use the jsreport CLI to import a prepared backup file (including the users) during the container's boot sequence. It keeps things clean and ensures your environment is identical every time it spins up.

Reverting versions can definitely be a bit nerve-wracking when the UI doesn't seem to sync up right away. If you're still having trouble seeing the changes or just want to double-check the file structure before committing to another revert, I've found that using a quick online text or metadata extractor can help you verify exactly what's in the report definition. It’s a nice way to troubleshoot without cluttering your local environment.

I’ve run into similar issues when trying to pull in external PDFs that weren't generated by the same template. Using the pdf-utils 'merge' or 'append' operations is definitely the way to go, but it can get a bit finicky if the source files have different page sizes or metadata.
If you're still having trouble getting the pages to line up, one thing that helped me was to 'pre-process' the external files first to make sure they're cleaned up or split into the exact pages you need before calling them in the recipe. It’s a bit of an extra step, but it usually stops those weird layout shifts or empty pages from happening during the merge!

That file is usually the internal reports store (depending on the provider you're using). If it keeps growing, it might be because report history/results are being persisted. You can limit or disable storing reports in the configuration (for example using the store settings or switching to a different persistence strategy). Also worth checking if there’s any cleanup/retention policy configured. Otherwise the file can grow pretty quickly over time.