Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

Flex box items / Bootstrap 4 rendering incompatibility with EOPDF Options
aceguy
Posted: Friday, April 13, 2018 1:47:32 PM
Rank: Newbie
Groups: Member

Joined: 3/8/2018
Posts: 5
I have run into an issue when utilizing HtmlToPDF to print a dashboard I have created in bootstrap 4 that contains number of widgets / cards laid out using flex. When I export a PDF it exhibits strange behavior where some of the cards jump down to a second page prematurely leaving a massive amount of space at the bottom of the first page. This behavior ONLY happens when the cards are in a particular order and I have noticed that it is when cards that have nested flex items (sometimes in the form of bootstrap .rows / .col-* 's) are in the 3rd or 4th position, coincidentally where the page break is prematurely forced. Otherwise, when not configured in this fashion, the first page of the PDF export contains 6 cards before "page breaking", which is what is expected.

Important Details:
- Everything renders properly in chrome, firefox and IE / EDGE.
- The Cards are all the same width and height based on a common template
- When exporting the cards are zoomed via CSS to 70%
- Dashboard layout flex wrapped
- The Card's each have page-break-inside: avoid. no other elements contain page-break css styles.
- I have even tried to set page-break-after and -before on the 7th card to try to force the accepted behavior, it doesnt work.
- Deleting the nested flex items inside of the card's body (when in the 3rd or 4th position) fixes the render.
- NOT deleting the nested flex items and instead disabling certain css styles on elements inside these nested flex items fixes the render.
- these flex containers / items are mostly done through bootstraps .Row and .Col classes.

I am completely puzzled and this point i am tempted to believe it is plainly an incompatibility somewhere between EOPDFs engine and nested flex items in specific scenarios.

I am using EO PDF Version 17.3.13

Any support would be amazing.
eo_support
Posted: Friday, April 13, 2018 1:56:27 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,466
Hi,

The most likely cause for this is because by default the EO.Pdf's internal "window" is a lot narrower than a typical browser window (because a typical PDF page is narrower than a typical browser window). To verify whether this is the problem, try to load the page into a regular browser window, then resize the browser window to quite narrow, if you see the same problem then this is the root cause of the problem.

If this is the root cause of the problem, try to set HtmlToPdf.Options.ZoomLevel to a value less than 1. This will increase the internal window size (by zooming out the content). For example, if you set ZoomLevel to 0.5, then the internal window will be twice as wide.

Do not use CSS zoom in your HTML to control zoom level. It will make issue much harder to troubleshoot.

If you still have problems, try to use the built-in debugger feature to examine the state of the HTML file when it's being loaded into the converter:

https://www.essentialobjects.com/doc/pdf/htmltopdf/debug.aspx

Please let us know if this resolves the issue for you.

Thanks!
aceguy
Posted: Friday, April 13, 2018 2:39:37 PM
Rank: Newbie
Groups: Member

Joined: 3/8/2018
Posts: 5
eo_support wrote:
Hi,

The most likely cause for this is because by default the EO.Pdf's internal "window" is a lot narrower than a typical browser window (because a typical PDF page is narrower than a typical browser window). To verify whether this is the problem, try to load the page into a regular browser window, then resize the browser window to quite narrow, if you see the same problem then this is the root cause of the problem.

If this is the root cause of the problem, try to set HtmlToPdf.Options.ZoomLevel to a value less than 1. This will increase the internal window size (by zooming out the content). For example, if you set ZoomLevel to 0.5, then the internal window will be twice as wide.

Do not use CSS zoom in your HTML to control zoom level. It will make issue much harder to troubleshoot.

Thanks!


Hi,

Resizing the browser windows very narrow does not cause any adverse effects. But also this is not something that would popup in a browser since the issue is that EO PDF is breaking up the number of cards that fits on one page prematurely. So essentially there is enough height on the first page for 6 cards to appear, but in some cases only 4 show, leaving the bottom half of the first page blank and putting the rest on pages 2 / 3.

Taking the zoom out of the print media query in css and instead changing the ZoomLevel DOES in fact fix the rendering issue.
But the whole reason I did it this way was because I would like to be able to control the zoom level of particular sections across various pages.

Is there any specific reason why using zoom level in css doesnt work with these flex items when exporting to pdf?

Thank you for getting back to me!
eo_support
Posted: Friday, April 13, 2018 4:44:33 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,466
Hi,

There is a bug in our previous version regarding CSS zoom level that would incorrectly calculate an element's size, which is used by the paging process. We believe this bug has been fixed in the latest build (.41 build). So you can give that build a try and see if it works for you if you wish to keep the zoom level. However generally we do not recommend you using CSS zoom because it makes layout issues harder to troubleshoot.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.