335
Views
14
Comments
Solved
[Ultimate PDF for Traditional Web] PrintLayout causes extra empty page to be created
ultimate-pdf-for-traditional-web
Web icon
Forge asset by Leonardo Fernandes
Application Type
Traditional Web
Service Studio Version
11.14.5 (Build 57418)

Goodmorning Ultimate PDF team,

So I was happy to read about the latest version being able to put multiple blocks on a screen to create unique headers and footers on different pages. Thank you for this possibility. Our customer wants to have a specific signature field at the bottom of the last page. So we thought to use an extra PrintLayout and use it's footer.

However, installing the newest version of Ultimate PDF for Traditional Web has one side effect for us: it creates an extra empty page for the first PrintLayout, only containing the header and footer. Currently we have 3 pages in the following example (screenshot only shows the 2nd page). Page 1 contains the correct data and page 3 as well. Page 2, however, is just empty except for the footer and header:

This is not expected behaviour that we would like. Is this a bug and is someone else also experiencing this? Does anyone know why this occurs?

I've tried the following:

- Removed the 2nd PrintLayout - has no effect.
- Tried to generate a PDF with less data on the first page, also no effect
- Rolled back the Ultimate PDF install to an older version - this worked but this version does not have the possibility of adding an extra PrintLayout with the unique footer (how the customer wants).

Please let me know any thoughts and ideas you have.

Thanks in advance!

Regards,

Michiel

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

Thank you Daan. I was able to reproduce the issue.

The second page is created due to the margin-top-xxl style applied to the first container of the page. This margin collapses with the remaining of the document, and causes some overflow creating the second page. I will fix this in an upcoming version, but a workaround would be to use padding instead: padding-top-xxl.

2019-09-30 07-35-56
Aurelio Junior

Hi Michiel,

Can you share a screenshot of your current widget tree, so I can try to replicate your issue?

2020-12-13 11-02-07
Michiel van Lokven

Hi Aurelio,

Thanks for your reply. Attached two screenshots of the widget tree (first the header, the second contains the main content and the footer.

Regards,
Michiel

2019-09-30 07-35-56
Aurelio Junior

Hi Michiel,

I was able to replicate the issue with a very simple report with just some static content in it. A second page with only the header and footer is always created. It looks like it's a bug in the component. If I were you, I would drop a DM to the component's author (Leonardo Fernandes) alerting him about this issue.

2020-12-13 11-02-07
Michiel van Lokven

Hi Aurelio,

I will contact him, thanks for your time to reproduce this problem!

Regards,

Michiel

2022-01-17 07-07-32
Daan Brandenburg

Hello Michiel,

Do you have any updates on this issue?

I am facing the same problem, but then with the Reactive version of Ultimate PDF.

Regards,

Daan Brandenburg

2020-12-13 11-02-07
Michiel van Lokven

Hi Daan,

Sadly not. I've sent a message to component developer, but no reply as of yet. I've reverted my version back to the old one sadly.

Initially I needed to have a different footer on my last page. I've have "solved" my problem by making a floating container using css that places it at the bottom of the page. The floating container allows you to place a specific container at a specific location on the screen using height and width parameters.

However, the problem with floating containers is that it ignores content of any other data on the screen. So you can get overlap of data if the other containers end up at the bottom of the screen. So far I have not found a way to place a specific container at the bottom of a page + keeping in mind the other data, so it does not overlap. 

To fix that problem, I've built normal container with the same content as the footer, but then just placing it at the end.  Users can use a boolean to either use the floating container or the normal container, depending on how it is printed as PDF. It doesn't win any prizes, but its a workaround that worked for my customer.

I hope this problem is fixed soon, so then I can really fix this problem.

Regards,

Michiel

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP

Hi. I wasn't able to reproduce this issue with a simple report, as Aurelio claims. Would you be able to send me a module that replicates this issue?

2022-01-17 07-07-32
Daan Brandenburg

Hello Leonardo,

Attached a simple module which produces a PDF with two pages.

Kind regards,

Daan Brandenburg

TestPDF_v4.oml
2019-07-08 11-04-35
Leonardo Fernandes
 
MVP

Hi Daan. I cannot use this module because it has many dependencies on business logic.

Would you be able to reproduce the issue with a simpler module, independent from any business logic?

Thank you.

2022-01-17 07-07-32
Daan Brandenburg

Hello Leonardo,

Is this a better version?

There are only dependencies now with the UltimatePDF component and OutSystemsUI

Kind regards,

Daan Brandenburg

TestPDF_v5.oml
2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

Thank you Daan. I was able to reproduce the issue.

The second page is created due to the margin-top-xxl style applied to the first container of the page. This margin collapses with the remaining of the document, and causes some overflow creating the second page. I will fix this in an upcoming version, but a workaround would be to use padding instead: padding-top-xxl.

2022-01-17 07-07-32
Daan Brandenburg

Thanks Leonardo!

By changing the margin-top-xxl to padding-top-xxl is was indeed fixed. 

I would mark your answer as the solution, but I did not start this thread

2023-04-14 11-47-10
Samuel Frade
UserImage.jpg
Daniel Raposo

Thanks for the answers, I had the same problem.

In my case, I just changed the margin-base to padding-base.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.