CSS Page Break Avoid Too Strict

[cud]

I just want to make sure I understand this correctly...

CSS says this:

Code: Select all

li  {

    page-break-inside:avoid;

}

should avoid a page break inside an li -- WHENEVER POSSIBLE (emphasis mine). In the PDF that I generate, if the li is very big, then it populates to the end of the page, and the following page starts at the next li. It does not start with the continuing text after an unavoidable page break. That looks to me like a hard rule to never allow a page break.

So my question... Is this the expected behavior, and I have to make separate break rules for every type of element that might be in an li? Or is there some way to make the "avoid" be softer?

AD-thanks-VANCE

[Costin]

Hi cud,

Yes, if you use the "page-break-inside:avoid;" declaration, this means that in does not allow page breaks at all inside the matched elements (in your case, inside the list items). This is how the "avoid" value works.
As a workaround, you could mark the large <li> elements in your XML by adding a custom outputclass attribute on them, then match them by their custom outputclass with an opposite rule. For example, a rule like:

Code: Select all

*[outputclass~="largeListItem"]  {

    page-break-inside:always;

}

would match any element with a "largeListItem" outputclass.

Regards,
Costin

[cud]

Yes, I think the problem is the usual engineer-speak that always prefers euphemism to saying what you really mean. In this case the standard uses "avoid" when it really means "prohibit". What I would dearly love is a true "avoid" where it tries to not use the page break, but will use it whenever strictly necessary. This is how typesetting works, really. I know this is not an issue for oXygen... Unless as a feature request you were willing to extend the CSS to include "avoid_soft" or some such. But I'm sure that's not in the roadmap for your priorities.

The problem with using a special outputclass value is that you break the cardinal rule of putting formatting info into the markup. I guess the better thing to do would be to trap the output XML, and if an <li> has more than X characters in it, apply the special outputclass there. Not sure I'm the XSLT hacker to pull that off!

[Costin]

Hello,

I logged this as a feature request in our internal tracking system.
However, as this is the way the page breaks work and this is also as it is defined in the CSS language (and compliant to the W3C standard), I can not guarantee this will be implemented, or tell when this would occur.

When/if this will get implemented, we will notify this thread.

Regards,
Costin

[cud]

Thank you Costin!!! I will say, if you can put oXygen a cut above for generating PDF, that could be a good differentiator.

I understand that you comply with the standard. I believe a number of people resist DITA to PDF because it's so difficult to generate decent output. If there could be a way to improve on this, I believe it would be a benefit to the community at large.

Thanks for taking this seriously!