Yes, it's a good start! If I have n documents in the app you will have to add the function at the beginning of each but it is not a big problem, thank you!
Remaining on the subject, there are 2 other issues related to double-sided management:
If I am within a cycle in a single report, how do I manage the jump page? Let me explain: let's suppose that I have to print a section in a report several times, and I want it to always start on an even page. Not having the $pdf.pages and not being able to use counters because we do not know how long the previous page can be, how could you do?
In the case of headers added via pdf utils using the merge whole document option, these are also rendered over the blank pages. Is there a workaround to prevent this from happening?
How is this configuration set up in an MVC controller using Local Reporting? I see a class AssetsConfiguration, but can't figure out how to get that to work in the .Configure syntax in C#. I don't see AssetsConfiguration as part of ExtensionsConfiguration or the main Configure class. Any help is much appreciated!
Thanks for following up on this - sure enough using plain old object fixed it! I think i used map originally just to see if newer ES5/6 stuff worked which i guess it does minus this serialization issue.
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 group property with some meaning.
As I mentioned, so far the consistency is winning for us. So we plan that group always 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