Export to PDF

[jordanh]

Issue - Enhancement

A user has requested:

I think a pdf that looks similar to the final meeting summary would be far better than the csv.
Just prettier and easier to access/deal with, say, if you post it to a slack channel.

Acceptance Criteria (optional)

Users can:

• Can view/download a PDF from Meeting summary email

• Estimated effort: 11 points (see CONTRIBUTING.md)

[tayamueller]

from this Scrum Master user:

I tried your website for the first time today with my team, and we loved it! The instant meeting summary email was great, however it would be great if there was an exportable version, so I can archive it so the team can reflect back. The CSV isn't much use for me I am afraid, as I usually store the results of our retro, such as attendees, action items from retro and usually a photo of our board (if done offline). I really liked the format of the email, so a PDF version would be great as I can attach this to our archive.

[gcrickman]

A user says:

Export to PDF feature of meeting summary at the end. (I am using PRINT to PDF via browser right now).

[jordanh]

Making this discussion

[jordanh]

Closing this for now

[drewhousman1010]

A user 🔒 writes:

It would be great if at the end of the retro, we would be able to export the summary to PDF/ JPG

[gcrickman]

A user 🔒 mentioned:

An additional feature - we would like to have a printed PDF version in a separate area that's not in Parabol itself. I know you can export it into csv file, if it's possible to download as a pdf, we just print the summary page

[gcrickman]

A user 🔒 asks:

Hello! How do I download the meeting after as PDF?

[gcrickman]

A user 🔒 asks:

Is there a way to export the "Reflections" in a pdf for easy reference later?

[atannus]

Hi all, here are some thoughts:

Summary

This seems to be a recurring request, even though it has a solution: Print to PDF.

I see this as a UX request, not really a feature request. It can be handled in at least two ways, both will require the addition of a "Get a PDF" or "Download a PDF" button to the interface.

I think both also require reviewing the CSS, since after all PDF is a print format. I'd at leat take care not to print interactive elements (such as buttons, links, etc) and try to get the content to paginate well, if possible. It is also possible to make the links work on the PDF document, but I would strongly adivse against writing URLs in stone like that. ;)

So, here are the two ways:

1. Button triggers window.print() and hopefully the user will know to pick PDF in case there is a printer configured as default.

• Not actually a download, but incorporates today's only solution into the UX.
• Is in fact handing off the user to their browser's UI, so no control or knowledge of what happens next, no option to send to email, etc.
• Requires minimal coding, the button and some css adjustments to make the page print-friendly as it will be split into distinct pages of unknown size (could be A4, letter, etc...).
• ?

2. Button triggers the download of a PDF file, generated eagerly when the meeting is over or lazily when requested.

• Requires deciding and coding the rendering of the PDF file, which can be done in numerous ways with pros and cons.
• If eager, requires storing these files, even if temporarily. How big? How many? For how long? Is this a problem?
• Opens possibility of a dedicated layout developed and optimized for print.
• Opens the possibility of a default configuration to always send such PDF to email.
• Opens the possibility of a dialog from which to choose: "print to pdf", "send pdf to my email" or "forward pdf to: [ ]"
• ?

3. ?

Here's what I think needs attention when exporting do PDF:

[Dschoordsch]

We should apply pageBreakInside: avoid to these elements. I think fixing the layout for print and adding a button is low hanging fruit and does not much future maintenance on our side. The button could also read as "Print as PDF".

We're rendering the email we send on the server and could use the same logic to also generate a pdf from it. A quick search showed only 2 packages https://github.com/mrafiqk/html-pdf-node and https://github.com/marcbachmann/node-html-pdf to generate PDFs. Both are using phantomjs or puppeteer, meaning they're relying on starting a headless browser just to print it. I don't have experience with these, but my gut feeling says this could put too much load on the server for little benefit. I would be reluctant to implement this and would be afraid it's just opening a whole new can of worms.

[enriquesanchez]

These are great suggestions, thank you @atannus!

The HTML meeting summaries are already stored and can be viewed later on. I don't think we would need to store the PDF version of it, since we can always perform a "download as PDF" action on them.

I like your suggestion of simply downloading the PDF. The actions could be placed in the same sentence, something like this:

Export to CVS or PDF

So if a user selects PDF, they will then have access to a PDF download that they can then store or share (or even print!) as they need.

A small detail but I think it's important to avoid confusion, is to avoid the word "print" and use instead "export". Based on the feedback and requests detailed on this issue, users want a way to export a PDF, and not really physically print it.

[jordanh]

@Dschoordsch could we not use Puppeteer in browser and distribute the rendering load to the edge (i.e. the user)?

[adaniels-parabol]

@jordanh @Dschoordsch what about jspdf (last update 3mo) or react-pdf (last update 15 days), both are more active in the community and updated more regularly.

pdf-puppeteer hasn't been updated in almost 2 years and old dependences will eventually bubble up in vulnerability scans and possibly make a headache for Ironbank.

[BartoszJarocki]

@jordanh @adaniels-parabol another way of doing that (and the way I did image generation API in the past) is to use puppeteer in some lambda function and simply generate the PDF. we don't worry about the load, our server is safe and users can generate pdfs. puppeteer itself has API to generate pdfs, no need to use outdated libraries:
https://pptr.dev/#?product=Puppeteer&version=v13.5.2&show=api-pagepdfoptions

there are a few issues with that, potentially

1. I'm not sure if the pageless format is supported
2. cold start of the serverless function
3. figuring out whether the client sends the data and the function is pure utility, or if the function can access our db
4. in general, starting up a puppeteer could be slow

[adaniels-parabol]

How would we support PDF generation for Gov DOD users who can't really use external services? PDF generation sounds like a common thing we wouldn't want to tie to an external API.

[BartoszJarocki]

@adaniels-parabol I thought about our serverless function, we could use AWS Lambda or something similar. so it wouldn't be an external API. unless I misunderstood you, there should not be any issues with that

[Dschoordsch]

@adaniels-parabol React-pdf looks promising and renders in the client. That seems ideal. We should give it a go.

[JimmyLv]

Yeah, after a brief look at react-pdf, it looks very reliable and has a very easy-to-use Hook API. react-pdf deps on Yoga layout (it's also an Facebook Open Source) and pdfkit (I tried this before and it's good).

We internally use Yoga layout to compute node's size and coordinates inside the document, and perform page breaking based on a set of customizable heuristics.

The creation of the PDF document itself. For this task, we use the awesome pdfkit.

[atannus]

I've gone ahead and implemented the bare minimum code to get that "low hanging fruit".

The implementation is very slim, just one new component which when clicked calls window.print(), and a minor changes to SummarySheet.tsx to include the new link.

As for hiding the buttons, that was done using .hide-print which was already available in the CSS.

I did not hide the "see comments" links above each ReflectionCard. These are quite useful and can be used in the PDF format, but I'm not sure about them.

Should I send a PR to master or a feature branch? Is there a nanimg scheme? What's the merge strategy?

[atannus]

I don't know if I should pull-request into master or another feature test branch, can someone help me with that, please?
Are there boxes to check before I put in a pull request?
Thanks!

[Dschoordsch]

@atannus you can open a pull request into master and then it will go through code review.
I would also like to know where you would look for this information, so we can add it there for the next contributor.

For the not so low hanging fruit, as it seems fairly straight forward I would love if you could give react-pdf a go so we could get a sense of

1. how much work is adapting the layout for it?
2. how much more dependencies does it pull into the frontend?

[atannus]

@Dschoordsch thanks, I'll put the PR in shortly.

I first went to CONTRIBUTING.md looking for instructions, it seems like a natural place, perhaps under or near "Git Strategy".

I took a brief look at react-pdf. I was initially hoping for a way to render the PDF directly from the webpage and its assets, just like the browser's "Print to PDF" feature, but from my very brief look at it, react-pdf allows the construction of a PDF, which would require templating one for that particular purpose, which in turns means twice the maintenance when changes are made to the Summary and other PDF-exportable pages.

I am interested in finding out if there is a way to render directly from the HTML on the browser, that would eliminate the need for a dedicated PDF layout. I'll give the whole thing a hard look and report back.

[atannus]

Here's a quick status update on this issue:

@Dschoordsch

• pageBreakInside: avoid apparently does not work within table, tr and td.
• node-html-pdf uses PhantomJS, which is abandoned: https://github.com/ariya/phantomjs and https://phantomjs.org/
• html-pdf-node seems to be just a wrapper around Puppeteer.

@jordanh

Puppeteer uses Chromium, which takes up 170 to 280 MB depending on the OS. It manipulates the browser on the server by default. You can set it up so it can be accessed from the web using puppeteer-web, but that goes against the idea of offloading that compute load to the edge.

Notes:

• html2canvas can be used to generate a PDF containing a "screenshot" of the page. I have implemented this experimentally, with pagination, in about 50 lines of code but the major drawback is the PDF will contain images, so not text-searchable, has no vector graphics, no links, etc. See test-pdf-from-canvas.pdf for a sample.
• jsPDF and pdfkit both allow for the creation of PDF files on the client-side, but both will require a dedicated layout.
• react-pdf does the same and allows this layout to be expressed using components that follow react primitive specs, and has a specialized API for styling. Example here.

This article was very helpful: https://blog.risingstack.com/pdf-from-html-node-js-puppeteer/

test-pdf-from-canvas.pdf

[atannus]

There is in fact the alternative to only implement PDF, which can be displayed on the page with option to download. The summary is a pdf. Major drawback I think of is the loss of interactivity beyond links...

[BartoszJarocki]

@atannus thank you for the PR, i just left some comments.

@jordanh @Dschoordsch are we good with the scope of the PR: #6420? It's basically using window.print

[atannus]

@BartoszJarocki I've spoken to @ackernaut about this, it turns out this has ramifications.

• This solution will not work when viewing the Summary Email
  • on web clients it'll print the entire webmail interface
  • on local clients it'll likely not work at all
  • no way to hide the button selectively for these two cases
• If printer is configured, button will open the Print interface and user will have to select "Save as PDF". This breaks what is expected of a button called "Export do PDF".

I've fixed the PR with the changes you've suggested, but I think @ackernaut needs to chip in, perhaps this is not ready for production.

[ackernaut]

Overall, I’m not sure this is worth the effort we’re applying:

• Email clients like Gmail and Protonmail have a printer button that isolates the email message. If folks only knew to save as a PDF instead of printing
• If folks are on the in-app, browser view they could open the print dialog, once again choosing to save as a PDF instead

I think the ‘save as PDF during print’ affordance is the best we can give them:

• If you use the MeetingSummaryReferrer you should be able to set a condition if the summary is being view as the email or from the meeting view. We could do something different in both cases, like send them to the print dialog in the meeting view from a button, or conditionally show a tip to save as PDF
• I wouldn’t mind dropping a small hint ‘click print, then set to save to PDF’ but that is a little clunky in terms of ‘don’t make me think’. They could click a button ‘Export to PDF’ that expands into steps: 1) open print dialog 2) set save as PDF 3) share with friends
• We could generate a PDF separately and attach it to the email and in-app views. This requires us to maintain another summary artifact which is not ideal. Once again, the juice has to be worth the squeeze
• I’d like the summary view in app to move away from tables and not be coupled to the email

I’d like to see an email notification system that mentions the simple event ‘meeting XYS ended’ and points them back to a rich summary view that we can control. Folks could opt in or out to this notification in app, email, or chat. All channels would offer a consistent notification that points to artifacts.

Folk would lose the in-email version they can pass around. Maybe the attached PDF makes sense there. I think in the long run we might be in the business of rolling up digests and highlights for management. I’m not sure we can do much more than give them teasers in email. The real deal will be in the app

In general, I’m okay with a small, less-than-perfect win but I’m not sure we’ve go the right direction here. How many people have asked for PDFs? How much of this do we have to maintain?

[ackernaut]

I think automated invoice emails with attached PDFs #3955 is another opportunity to use this learning. What I would imagine is that a configurable list of emails receives a clean email template about the invoice with an attached PDF of the invoice. They can tap through to see the invoice in the app. They could forward the email with PDF to their accounting or just add that accounting email and skip that nonsense.

[acressall]

A user requests:

Ability to export the summary to a google doc or pdf

[atannus]

It lives! :)

…

On Wed, Jun 29, 2022 at 2:01 AM Alicia Cressall ***@***.***> wrote: A user requests: Ability to export the summary to a google doc or pdf — Reply to this email directly, view it on GitHub <#2730 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFDNGZG2IVKRHAKLW47PZDVRPKBDANCNFSM4G63ZTXQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- André Tannús | Epungo | +55 11 2389-4360 We are a layer

[acressall]

A user would like:

Getting a detailed report of the meeting in PDF (currently it is only possible to export it in CSV, or to print/download a summary that does not show the comments and tasks)

[ackernaut]

I propose we icebox this, and not collect signal for 2022 T2 or T3.

I think we have more interesting ‘activity output’ opportunities that are more strategic and interesting. The closest we’ve got here is giving people instructions or a not-above-the-bar button to basically Print > Save to PDF. Which they can do anyway.

We also have opinion that we may not generate invoice PDFs, but maybe just send an email and make it easier to print there. I’d rather start there first.

Also we probably won’t get to this among other things, and with folks like @atannus atannus I’d rather have help for more interesting things.

Since this is safe to try (we can reopen this issue and resume collecting signal) gonna err toward action. Happy user feedbacking!

[atannus]

@ackernaut hit me up when you come across something I can help with.