Automated `window.exportPdf()`, Leveraging Browser's Print Save As PDF functionality

apurvaojas commented 2 months ago

What problem are you trying to solve?

Generating a PDF from a web page today is primarily achieved through the window.print() API, which requires user interaction (via a print dialog) to save the page as a PDF. This approach lacks programmatic control and is not suitable for headless or automated environments where PDFs need to be generated and handled directly by the application. Developers are forced to rely on third-party libraries (e.g., jsPDF), which:

Are inconsistent across browsers.
Often have significant performance and rendering issues.
Can be overly complex when generating PDFs from dynamic, styled content.

The current methods do not provide a native, efficient way to export a web page or specific parts of it as a PDF programmatically, leading to fragmentation and varied developer experience across applications and platforms.

What solutions exist today?

window.print() API:
- Pros: It leverages the native browser’s PDF generation capabilities via the print dialog.
- Cons: It requires user interaction and cannot be automated for scenarios like Exporting of report from UI, From UX point of view its hard for users to print and save as pdf, as it is not the default selection.
Third-party libraries (e.g., jsPDF, html2pdf):
- Pros: Offer programmatic control over PDF creation, enabling developers to generate PDFs without user interaction.
- Cons:
  - Complex setup and additional dependencies.
  - Inconsistent output across browsers.
  - Performance issues with large or complex pages.
  - Limited support for maintaining CSS and layout fidelity.

How would you solve it?

We propose adding a new window.exportPdf() API to the HTML DOM. This method will allow developers to programmatically generate a PDF of a web page or specified DOM elements, returning the PDF data as an ArrayBuffer. The API will leverage the browser's built-in PDF generation (the same functionality used by window.print()), but without requiring user interaction.

Key features of the proposed API:

Programmatic PDF generation: The API will return a Promise resolving to a custom object (ExportedPdf), containing the PDF data as an ArrayBuffer.
Save capability: The ExportedPdf object will include a save() method to allow easy saving of the PDF file to the user's device, providing an easy way to download or prompt the user to save.
Native performance: The API will use native browser capabilities, ensuring faster and more reliable PDF generation compared to third-party libraries.

window.exportPdf()
  .then(pdfBuffer => {
      // use buffer to automatically download file or Open SaveAs Dialog
  })
  .catch(error => {
      console.error("PDF generation failed:", error);
  });

This approach addresses the pain points of current solutions by:

Eliminating the need for user interaction.
Providing a consistent API across browsers.
Offering developers full control over the generated PDF and how it is handled.

Anything else?

Security Considerations: To avoid security risks, cross-origin content (e.g., iframes, images) will not be included in the exported PDF unless explicitly allowed via CORS headers. The API will also respect content security policies (CSP).
Accessibility: The generated PDF should maintain the accessibility metadata (e.g., ARIA labels, semantic HTML elements) of the original DOM to ensure that accessible content is preserved.
Performance: The API will be asynchronous to prevent blocking the main thread. By using browser-native PDF generation, it will offer better performance and fidelity than JavaScript-based PDF libraries.
Privacy: Care should be taken to ensure that no unnecessary metadata (e.g., user data, browser version) is included in the generated PDF.

This API would simplify PDF generation tasks for developers, improve performance, and reduce reliance on third-party libraries, leading to more consistent user experiences across the web.

annevk commented 1 month ago

This isn't viable for the same reason we don't support screenshots. That would leak information about what is displayed on the page.

flashymittens commented 1 month ago

Shouldn’t it simply show Save As dialog? If you want to modify the result, simply build a DOM you want before you export it.

apurvaojas commented 1 month ago

This isn't viable for the same reason we don't support screenshots. That would leak information about what is displayed on the page.

Agree with @flashymittens,

window.exportPdf(<OptionalDomNode>) which will export Given Dom as an argument.

Also people can use @media print to control the display of data.

Many peoples are already using client side PDF generations using different third party libraries(jsPDF usage stats), And it is application's responsibility to control what should be visible and what should not.

From browser's API point of view we can control generic security concerns (for example: Restricted access to this API from browser plugins etc.)

whatwg / html