Future outline for the NuxtPDF module (v1.0.0)

[zoey-kaiser]

Goal

Outline how development on NuxtPDF will continue. Decide on what to implement and how to properly execute on it.

Context

When first developing NuxtPDF we set a goal of adding a module that lets you convert Vue components into a PDF. This was done by using a html-to-pdf library. The vue component would be compiled to html and then rendered via the library. However, this method has many drawbacks, which lead to us not adopting this module into our development flows:

• Shifting layouts based on monitor size
• Missing styles, which leads to a different render from the actual component
• Complex components did not render properly
  • Forms were not editable in PDFs
  • Some texts were mismatched
• Defining a fixed page size is hard to complete properly.
• PDFs cannot be properly shared or reproduced

Therefore, we want to rewrite NuxtPDF to utilize a new method of PDF rendering that does not depend on rendering html to a PDF. This will make the PDFs more "stable" and allow for more complex PDF generation.

Server Side generation

In order to achieve this, we will move away from rendering html to a pdf and utilize a programmatic approach to define PDFs. For this we will make use of pdfkit, which includes functions to generate parts of a PDF. While this is not as easy or quick as developing a component and using it as a base, it will add the needed stability as well as allowing us to generate PDFs on the server side.

However, after testing pdfkit in our own projects we also noticed some shortcomings:

• Very basic functions to create PDFs
  • Does not contain complex rendering functions (such as tables)
• Confusing to begin development with
  • You have to impement it for Nuxt
  • Drawing lines, or changing font sizes is teady and hard to do
  • Requires a lot of self written helper functions to maintain consistency in a single PDF
• Previewing changes requires a reload on the server side, which may cause the entire application to crash (bad DX in general)

Improvements for Application side generation

This is pretty simple, but I plan to add a small collection of utility components, that can be used to properly structure the vue component. A few of these include:

• DocumentPage - which lets you select the page size (A4, A5, etc.)
  • It will then allow you to create your PDF inside this confined space, to properly align and format it even in the vue component itself
• DocumentTitle
• DocumentFooter
• DocumentTable
• Maybe more, depending on what I think of / gets requested.
• Better language support (Arabic Language Support #10)

The point of these components, is to make the start a lot easier. They will be "invisible" components, that only aim to help properly structure the page.

In addition to this, I also want to expand the docs to tackle:

• Custom fonts (also other alphabets)
• Integration of component libraries

Roadmap

In order to improve our module and maintain a high level of Developer Experience, we will implement the following features. Some features will be deprioritzed and pushed to later, to ensure we have a working minimal version before completing a full implementation.

• Including pdfkit and its functions on the server side via a nitro import
• Wrapping pdfkit in a custom function to include:
  • Injecting Data (with a zod schema or TS type)
  • Setting a "universal style" for the PDF via a config, that can be reused
    • This config will also be used for any "custom" components we include
    • This config will be simplied compared to the full config provided by pdfkit
    • This config will handle page breaking behavior
  • New Layout system.
    • Define a custom header and footer for the PDF. This header will be used to determine page height, page breaks and be inserted onto every page
    • Option to define a custom unique header for the first page, as this is often needed
• Better DX
  • Nuxt DevTools integration, to find any defined pdfs (via folder?) and display them in localhost:3000/__pdfs or via the Nuxt Devtools.
    • Sidebar that allows you to see all defined PDFs
    • PDF Preview with the generated PDFs
  • Ability to define mock data based on the zod schema or TS type
    • Future: Allow for multiple different mock data setups for proper edge case handling (a bit like a simple version of a storybook for PDFs)
• Custom components (a list of custom components we have already developed internally or we will need)
  • Header component
    • Just Logo
    • With Layout for letters (with address of recipient)
    • Page numbers
    • etc.
  • Table component
  • Divider Line component
  • Text sizes (H1, H2, H3, p etc.)
  • Dynamic boxes (with information and custom widths / heights)
  • Futhur components to come

This will allow us to have a solid base to work on PDFs in the future. While it is more complex then the current system, I think it will improve our PDFs as well as the DX compared to the native PDFkit package. Future expansions will include more components and improve DX even more. As someone who worked a lot on PDFs and with PDFKit I think the main features that contribute to this Modules worth are:

• Layouts
• Page breaking
• Components that can be reused

[fanckush]

this is great!

i'll test out the alpha release.
Looking forward to those components!

[zoey-kaiser]

@fanckush thanks for your interest ❤️

I have already begun working on the core logic needed for many of these features to work! Free free to give feedback to me while you work. I will also be using this in a few internal projects and adding components and features based on what we need!

You are also welcome to propose or add new components, that you need. Feel free to also add me on Twitter or Discord (tsuuki) if you want to discuss more!

Note: There will still be some breaking changes to come that I am already aware of. Ill try to document these as best as possible!

[fanckush]

First thing that comes to mind when checking the initial SSR PR and while trying it myself:
Using PDFKit makes sense since it supports node, that said, trying out a test PDF felt very different compared with client side generation. Client side is declarative (declare some html -> convert to pdf) while the other is imperative

it's a lot to ask since the underlaying tech is different, having the ability to pass in a vue component (e.g.: invoice.vue) and generating a pdf off of that on the server side would be incredible DX.

PDFKit doesn't support that of course, one would need a headless browser (e.g.: puppeteer). I don't know the scope of this project, maybe going that far is beyond the goals of this project.

Even on my project, i'm not sure what to do here 😅 I would love to define my invoices in simple vue components but I also would love to generate that on the server side and get the benefits of consistency

[ReaperMaga]

I like it! This looks very promising :)

[Celibioux]

Very intersting module 👍 Thank you for your great work on this
Do you have a nightly / next release to test the Pdfkit Intégration please ?
And how i can help with the Arabic Language Support ?