Print whole report to PDF

[mehmetoguzderin]

When converting to PDF using browser's printing functionality, due to iframe, it produces a cropped page. Correction of this functionality is important for contexts that have more traditional measures but open to converting from any platform.

Example notebook:
https://alpha.iodide.io/notebooks/3427/?viewMode=report

[wlach]

@mehmetoguzderin as I mentioned in the meeting, I think it might be worth trying to print just the iframe using the window.print command:

https://developer.mozilla.org/en-US/docs/Web/API/Window/print

The mechanism to call this would be the eval frame's port to the editor:

https://github.com/iodide-project/iodide/blob/69409c8f70731ed83ee18da828e3cb66ca966982/src/eval-frame/port-to-editor.js

We could experiment with adding a "Print" button beside "Explore" in report view, and adding an option to the menu in explore view.

Are you interested in giving this a try? It might not be that difficult if we're lucky...

[mehmetoguzderin]

@wlach Yes, I would like to try it on the weekend.

[wlach]

@wlach Yes, I would like to try it on the weekend.

Excellent! I'll assign this to you for now

[mehmetoguzderin]

@wlach Great!

[bcolloran]

re UI/UX, i think we need a better approach than adding another button in the top corner.

but it looks like maybe we can intercept attempts to print and trigger custom logic, so maybe we don't need to change the UI at all?--
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeprint

[wlach]

re UI/UX, i think we need a better approach than adding another button in the top corner.

Yeah agreed, that was just a suggestion for a first pass.

but it looks like maybe we can intercept attempts to print and trigger custom logic, so maybe we don't need to change the UI at all?--
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeprint

That sounds perfect! The best UI is no UI.

[bcolloran]

fwiw: off the top of my head, i think the way to do thiswould be something like:

assuming the print call is sent to the top level window and doesn't somehow cascade down to the iframe:

• we would want to intercept the print call in the editor window
• if viewMode = explore, do the normal print action
• if viewMode = report, send a signal down to the iframe to trigger printing...
  • re-layout the page for printing
  • call window printwindow.print()
  • restore the normal report view layout

[mehmetoguzderin]

@bcolloran @wlach

Unfortunately window.onbeforeprint does not affect the printing mechanism, the changes there are not always reflected in the print action; and neither its window.matchMedia substitute does on the devices I have tested. Although we can intercept control print combo, I am unsure how Iodidic it is given that on mobile devices, the preferred way to go is a UI button on the browser to trigger the export process. I am creating a pull request that provides a solution that works with the notebook I have provided in the post.

[bcolloran]

I'm opposed to adding another button to the report view -- we want the report to be as clean as possible, and to focus on user content, and we therefore we want to be very judicious about adding anything anything in that view. My belief is that for an online-first communication tool, print functionality will be very niche, so adding clutter to the report view to support it is not a worthwhile trade-off.

@mehmetoguzderin can you clarify what you mean about "window.onbeforeprint does not affect the printing mechanism, the changes there are not always reflected in the print action"? MDN indicates that these methods are specifically designed to allow one to change the layout of a page for printing:
https://developer.mozilla.org/en-US/docs/Web/Guide/Printing
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeprint

Perhaps we can try a printing stylesheet or media query:
https://developer.mozilla.org/en-US/docs/Web/Guide/Printing
https://stackoverflow.com/questions/21743383/print-inside-iframe-media-query
(Though I suspect that the binding difficulty will be using CSS in the top-level scope to set the height of the iframe to match the height of content within the iframe, which has been a challenge before)

[wlach]

I'm opposed to adding another button to the report view -- we want the report to be as clean as possible, and to focus on user content, and we therefore we want to be very judicious about adding anything anything in that view.

I understand the sentiment (and agree with it) but IMO, hiding a print option behind a ... button (which could also hold other things) would not be so bad. E.g. gmail does this for viewing messages: