Explore print.css

[josevalim]

Today we cannot print Livebooks. We should explore making them printable via a print media query.

[josevalim]

Depending on how much work we want to put into it, there is:

• @page rules - https://www.smashingmagazine.com/2015/01/designing-for-print-with-css/
• With polyfill: https://www.pagedjs.org/documentation/cheatsheet/
• https://print-css.rocks/

[juhalehtonen]

I had a very cursory look at this, reporting below for anyone who's interested in tackling this 🙂

It seems that the biggest bulk of work will be in handling the styling of iframes (such as the output of VegaLite), due to how they are positioned in a container element (see js-view-iframes) and then absolutely positioned to an expected location and size. I did not look into how much work there is to place the iframes statically when printing, or otherwise adjusted to act correctly. Whoever will look into this, see

livebook/assets/js/hooks/js_view.js

Line 183 in 52f7d74

createIframe() {

for more details on how and why this is done.

The above assumes that we'd not be using some fancier tooling for generating as-seen-in-the-browser documents for printing, as brought up by José above :). If an additional tool of some sort is used, the work with iframes can probably be sidestepped (at the cost of not having browser-native print support).

The "basic functionality" of print styling (as reported by the linked issue) in a way that enables printing the text-based (or any non-absolutely-positioned) contents in full should be achievable with a few lines of CSS in @media print { .. }, or whatever the respective effort is with Tailwind.

The main points of interest in getting the basic printing to behave correctly are 1) hiding the navigation/floating elements with a simple display: none, 2) changing the overflow-y in the main container to initial or other non-auto value, and 3) possibly changing from display: flex in the parent container to block or other value to avoid unexpected cut-offs of text when printed. Point number 2 is the main offender which currently prevents more than one "page" of content being printed.

[josevalim]

Thank you @juhalehtonen! There is also a related issue in #1159, where for complex printing we would rely on Pandoc and then get support on all of its outputs. In that case, we would have print.css only for the basic, in browser use cases, as you mentioned.