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

PageBreakRange and margins Options
nikfe
Posted: Thursday, November 9, 2017 6:52:43 AM
Rank: Member
Groups: Member

Joined: 5/25/2015
Posts: 17
Hi

I was trying to update newest EO to PDF but I got a lot of paging issues (we use our custom pager). Issue I found is that elements PageBreakRange now includes margins. Because many elements contain top and bottom margins by default and in html world margins collapses => many elements have now overlapping ranges. This currently means that "page-brek-inside: avoid" means also "page-brek-before/after: avoid".

This probably relates to release 17.2.75: "Fixed HTML to PDF converter not consider element margin during paging process issue;".

What is purpose of this change? Is there maybe some discussion in forum? I think PageBreakRange should match as close as possible to visual element ranges which is border box.

So how paging should be done now with custom api?
-Should we recraft all stylesheets so that there are no collapsing margins?
-Or...?
eo_support
Posted: Thursday, November 9, 2017 1:07:20 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,749
Hi,

This was a catch 22 situation. There are two different types of page break avoid: 1. page-break-before/page-break-after, 2. page-break-inside. While page-break-inside is rather straight forward, page-break-before/after is not because there is no clear definition of what's before or after a given element --- the element before or after a given element inside the DOM tree may be visually far away from the given element. As such for before and after instructions, we create a narrow "avoid" band that is not based on any element, but purely based on the top and bottom location of the element.

In order for this narrow band to have an impact on paging, it must overlap with the element that you really want to stick to. If we do not count margins when we create this narrow band, the margin values can easily exceed the size of this band thus results in this band to be completely within the margin and not overlapping with anyone. The net result is page-break-before:avoid and page-break-after:avoid would not have the desired result.

Your case on the other hand involves page-break-inside. It does seems to make more sense for page-break-inside: avoid to exclude margins. We will have to look into this and see if we can distinguish the two cases and use different values. Of course if you use custom paging it can make it even more complicated since you may have to decide which range to use. So we may need to modify/extend our API interface in order to support all scenarios. We will look into this and see what we can do.

Thanks!
nikfe
Posted: Friday, November 10, 2017 5:15:29 AM
Rank: Member
Groups: Member

Joined: 5/25/2015
Posts: 17
Thanks for quick reply and understanding (as always).

If you end up to just make api changes please don't make paging range to be different when page-break-inside | page-break-after. Purpose of paging api is to be low-level so don't ruin it by side effect magic heavy design :D I think best solution is just add more information: give border box range and margin box range. Of course if you want include this "auto range" feel free to do so but include raw data too please.



Our approach to this problem

Yes that's issue which we noticed as well. Approach we took was that page-break-before/page-break-after always create this "band" to next range where page-break is avoided. 'Next' means next in terms of coordinates (not structure) and including of course single text lines. This works very well in practice and even tough our pager is not perfect either this part is solid.

At the end page-break-after says that "put _something_ after me". If you have next element:
-paragraph => You got at least first line (and full para if inside: avoid)
-table => In general it will be drill down table -> thead -> tr -> th -> text row, so you have control as expected what is level where you avoid page-breaks.
-image (without inside: avoid) => We simply take full image and keep looking next avoid range. I think this may be "incorrect" in some sence but only realistic option with given information could be that random slice from image would be taken with first element but I cannot think any real situation where this would be actually wanted or messing another rules.

This work so far we agree that one "law of paged html" is: every element should have descedant element (or text row) with page-break-inside: avoid in every sub structure to be meaningful visual element. So this 'law' basicly says that last example about image without page-break-inside is style error. If you have counter example against this logic please challenge.

Btw just in case you have now warm and fuzzy feeling about your current solution here is some paging challenge for your current approach:

Code: HTML/ASPX
<style type="text/css">
	.pre {
		background-color: #AFA;
		border: 1px solid #0A0;
		height: 600px;
		page-break-inside: avoid;
	}

	.container {
		display: flex;
		flex-direction: column;
		justify-content: space-between;
		height: 600px;
		border: 1px solid black;
	}

	.container > * {
		page-break-after: avoid;
		page-break-inside: avoid;
		border: 1px solid #A00;
		background-color: #FAA;
		height: 200px;
	}

	.container > *:nth-child(even) {
		background-color: #AAF;
		border-color: #00A;
	}
</style>
<div class="pre">We want break after this</div>
<div class="container">
	<div>A</div>
	<div>B</div>
</div>


Remember that margins aren't only fundamental which moves elements. Btw approach I described solve this correctly.

As side note: flex box and grid layouts have another tricky property: structural order is NOT visual order. For example css rules order and flex-direction: column-reverse. We actually have some of these in our documents and we concluded that "page-break-after" means "do not break after this element" (visually) VS "stick with next element in structure" => so we still just think before and after in terms of coordinates.
eo_support
Posted: Friday, November 10, 2017 10:00:15 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,749
Thanks for sharing. Your approach makes perfect sense and I think we should implement it the way you described. If we have any questions or update we will reply here again.


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.