- From: Mike Bremford via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Jan 2023 19:24:37 +0000
- To: public-css-archive@w3.org
Sorry, a bit late to this. Some testing in various print formatters via https://printcss.live: * PrinceXML, Vivliostyle and page.js will accept `size: 0` and will create a 0x0 page. AH Formatter, BFO, PDFReactor, typeset.sh and Weasyprint will not accept 0x0 as a page size. * When given a margin size that would result in the content area being less than or equal to zero, AH Formatter, PDF Reactor, Prince, typeset.sh, Weasyprint all complete. Vivliostyle and pagejs crash, as does our own BFO Publisher (now on my TODO). As an aside, PDF prior to PDF 2.0 also _recommends_ a minimum page dimension of 3pt (4px). Going below this gives errors in Acrobat, weird results in macOS Preview.app, and in general I wouldn't expect pages smaller than this to be reliable rendered in PDF applications. I appreciate "recommends" is a bit woolly, and I also appreciate PDF is not the only game in town, but "vastly different behaviour" is what you're going to see for pages less than 4px on any side. I don't see why PDF's failing here should impose similar limits in CSS, but a note to that effect might be useful. So I agree that `size:0` should be treated as `auto`. But the _page area_ (the inner dimensions after subtracting the margin) of <= 0 does seem to be widely accepted - it's no different to any other cases where content overflows. The results may not be useful, but they're not invalid - layout can complete. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8335#issuecomment-1400862695 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 January 2023 19:24:38 UTC