Page break: always works but: avoid doesn't

[martinevans2]

I followed some guidance to say ol { page-break-after: always; } and it worked - all lists have a page break afterwards.

But when I do page-break-after: avoid, it doesn't work. It doesn't do what my browsers do when printing to PDF, which is to push that element onto the next page if its next sibling doesn't fit.

Does anyone know of a workaround?

[elliotblackburn]

We use showdownjs to convert the markdown to html and then push the html + css into chrome via puppeteer. If you run the debug flag (see readme for info) you should be able to check the output html. If you open that in Chrome and print it to a PDF you should be able to see if chrome is producing the same result or not.

If it's not then perhaps we need to do some package version bumps. Although I'm not sure how quick that would be as I've not had time to dedicate to mdpdf for some time now.

[martinevans2]

Hi Elliot, I can confirm that the HTML contains the correct CSS for avoiding page breaks. And when I open that HTML in Edge and print it to PDF, it respects the page break avoidance. I can trim the margins such that the element would fit on the page but is placed on the subsequent page due to its CSS. And yet the mdpdf process somehow fails to achieve this. No worries if you're not actively developing the tool but it does appear to be a bug.

…

On Wed, 11 Jan 2023 at 17:40, Elliot Blackburn ***@***.***> wrote: We use showdownjs to convert the markdown to html and then push the html + css into chrome via puppeteer. If you run the debug flag (see readme for info) you should be able to check the output html. If you open that in Chrome and print it to a PDF you should be able to see if chrome is producing the same result or not. If it's not then perhaps we need to do some package version bumps. Although I'm not sure how quick that would be as I've not had time to dedicate to mdpdf for some time now. — Reply to this email directly, view it on GitHub <#152 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A43OX5CYYEGQFIRZMEYFPEDWR3V7TANCNFSM6AAAAAATX7CDCM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[elliotblackburn]

Once we've processed the HTML we use Google Puppeteer (Chrome) to do the HTML -> PDF step. If you open the file in Chrome and save to PDF you should get an identical output (accounting for our CLI flags and the fact we're on an older version of puppeteer).

You are right about it being a bug, but mdpdf just shims between Showdown (MD -> HTML) and Puppeteer (HTML -> PDF) so rendering differences and how CSS is processed is generally on the Puppeteer side of the fence and there isn't much we can do past bumping the package version.

Doing it manually in Chrome should tell you whether it's the way Chrome works, or whether we would need a package bump.