PDFUtils Not Respecting FontSize on Template Merge With Large Dataset?
-
I wasn't able to get a playground example to reproduce the issue. I'm working around the problem by not merging my index template and instead just appending it though I lose table of content links this way. I also have to hardcode my font-size to 18pt font for it to be similar to my main template with the same font at 12pt. Its really strange.
I could reproduce with my local production dataset by removing completely random entries until it was small or fast enough to render with the correct font. Something about timing? with merging a template and using pdfUtils...
-
Please email me your export including the dataset if possible.
I would try to find out where is the problem.
-
I will have to check with the company if I can do that. In a crunch to finish this as I've been trying to get a product working for a month now.
I had another problem with my workaround but was luckily able to identify that for some reason having
width: 100%, height: 100%on one of my components was making only one page of the content render. There were 4 sections that should be 32 pages long and it would only render 1 page of each section.
-
Im frequently getting this error in the studio but re-runing the request usually fixes it, there error is not very clear as to what or why its happening but its concerning that when I move these changes to production it will continue. Is this in my code? It seems to occur after a successful run on the next attempt.
-
It was also very very very slow rendering speeds (or never finishing) when using {{component }} and had to remove 15+ components and just embed everything in my main template to increase render speed. I thought the components were supposed to help with speed? Specifically where I was rendering a Person type of object and it used a component called Attribute like 20 times, and then I was rendering thousands of Persons.
-
My font size problem may have been related to the width/height problem I had after changing how I was rendering indexes. I'll have to circle back to that version of code and see if it was the root cause.
-
I'm unable to email or share our code so I guess I'm out of luck unless we purchase a support package and demo the problem over a call.
-
Im frequently getting this error in the studio but re-runing the request usually fixes it
We have a fix for this which will be part of the 3.6.0. The error is just coming from the studio parsing very very long profile. It shouldn't happen for API calls.
I thought the components were supposed to help with speed?
Components are there to decompose the code and improve performance compared to the child templates. It won't get faster than having one monolith. However, the degradation shouldn't be so dramatic.
I'm unable to email or share our code so I guess I'm out of luck unless we purchase a support package and demo the problem over a call.
We anyway typically need the problem replication so we can analyze it deeper. That is often an hours-long process not suitable for calls. I understand sharing data is problematic, but often it's enough to anonymize the values. You can email it then privately without exposing it here.
-
Thank for the additional answers Jan Blaha! Very helpful and boost my confidence. I'm unable to share more code due to my company policies, if I get time I will try to create a simple playground that can reproduce the issue I was seeing.
-
Is this just a warning in 3.5 or is it slowing down my pdf generation?
production jsreport instances should use enterprise scale license which doesn't limit the license key usageSadly switching from a manual (terrible) paging solution that was using PUG to render html to Handlebars and pdfUtils has increased generation time 10x.
-
Is this just a warning in 3.5 or is it slowing down my pdf generation?
The generation isn't affected by licensing.
