PDF Utils: pdfCreatePagesGroup not working as expected
-
I have a simple use case that I'm trying to implement. When the content of a report section expands across multiple pages, I would like to re-print the section name in the header. Because the section lengths can vary in size, I do not want to force a page break resulting in a lot of white space. I'm trying to implement this using PDF Utils groups.
I have created a simple example of this in the playground (https://playground.jsreport.net/w/anon/ASmqFi2M). I would expect page 2 of the report to have a header of 'Section 2 (continued...)' but it incorrectly says 'Section 1 (continued...)'. I logged the $pdf object in the header and I don't see 'Section 2' in the object anywhere.
-
Any additional information I can provide to get a response and some insight on this? While this is a distilled example, I'm an enterprise scale licensee trying to use jsreport to solve real world business problems. Thanks.
-
No more input needed. Thanks.
This looks like a bug - if there are more groups on the same page we take the first one and we should likely take the last one instead.
I will consult it with other devs before we change this behavior.
-
To summary this.
The current behavior is that we always take the first group on the page and use it until we get the next one on the next pages.
Your example has shown this is wrong. If there are two groups on one page and nothing on the second one, the second page should be definitely marked with the second group.
That is clear.
There is a dilemma what group we should use on a single page with multiple groups. If it should be the first one or the last one.
We decided to be consistent and just use always the last one.
This means that on your example both pages will be marked with the second group.We've already implemented this and you can get the change using
npm install jsreport/jsreport-pdf-utilsHowever, we will be thankful if you have any other inputs or suggestions. Specifically regarding the dilemma I mentioned.
-
Thank you for the quick delivery of a patch. I definitely understand the dilemma that you describe. I'm sure the patch will not fit everyone's use case. How feasible would it be for each page in the $pdf object to have a firstGroup and lastGroup property? The report developer could then decide which to use in the header. The header could also show the "range" of data on the page. For example, if the report shows data on students, the header of each page could show "Student A - Student C", "Student C - Student F", etc. Perhaps there is a way to already do this effectively using items? I'm trying to avoid any solution that requires the "render for every page" strategy as the performance gain by "merge whole page" is significant.
-
How feasible would it be for each page in the $pdf object to have a firstGroup and lastGroup property?
Yes, we will provide another property for such cases. However, we don't want to break API now and we need to keep the
groupproperty with some meaning.
As I mentioned, so far the consistency is winning for us. So we plan thatgroupalways represents the last group.
I can imagine some users would like to have the first group, for the page where are multiple groups.
In this case, I think they will have to use the extra property.
Bad dilema, I really don't know what is the mainstream here, so we will keep it consistent I think.performance gain by "merge whole page" is significant.
Yes, that was done recently because of the performance gain
