Elements that are placed in page regions are shared between pages with the exception of CSS generated content such as running headers. Shadows are attached as an XObject image with a SMask indeed :)
We indeed price starting at $0.005 per document, but have slightly updated the pricing following the good input we received yesterday from the community - hence the slight discrepancy in comments.
We actually take HTML as an input to our API converter. The React tooling is mostly to ease the barrier with most frontend codebases, as well as leverage the existing ecosystem of components.
It seems that these conversion engines are massive pieces of work that require a lot of upkeep, partly because CSS is a living spec but also because of the sheer number of edge cases.
We are already working on SOC2 as this has been a recurring ask, and indeed documents almost always contain PII.
Really like your approach! We tried to keep things tied to code as much as possible rather than dealing with complex interfaces between changing inputs and outputs. Most legal and tech teams we talked to pointed to the fact that CI/CD would quickly become unbearable when decoupling documents and code implementation. What is your approach on that?
There are many reasons behind it, to name a few: files are self-contained(*) and easily portable, can guarantee some security features, the format is easily extended, and the ecosystem is very large.
It seems that a better format should exist, but the fact that PDF is the de-facto for portable documents make it unlikely things can change overnight.
You are right in the sense we do not provide a local library. We considered the option but would have brought a lot of challenges to accommodate the various runtimes and device capabilities.
This may come at a later stage once we have built our own rendering engine though
We bill per document, so the number of pages wouldn't impact the pricing. A 5 pages invoice would come at 1 cent per page. However, it seems that each and every company has different needs and the pricing may or may not make sense for them. There are alternative billing options that we are considering but we want to keep it easy to grasp rather than go into billing kilobytes or ms of execution. We would be more than happy to discuss use cases and see what can work for each company :)
While this may sound a bit counterintuitive (maybe?) we actually pivoted to this field based on YC input and discussions they have had with their previous companies. The multitude of FOSS solutions in this area indicates this is a real problem people are willing to spend time on, and yet there is no go-to solution and every team we have talked to selected different tools based on a very specific requirement.
This may not mean success, it means that game is not over in the documents field :)
It is similar to pspdfkit. We add an abstraction layer over the HTML and assets hosting to make it easier to use without having to think too hard about security and serving assets.
We also hope to keep the focus on the PDF generation part rather than expanding super-horizontal style to provide all imaginable PDF tools at the expense that none is really good.
This brings its own set of challenges. Headers and footers are strictly limited in terms of features, you cannot add footnotes, the notion of page spreads is harder to implement. Then you need to combine that with having a Chrome instance at hand + exposing the needed assets for URL resolution. Definitely not difficult let alone impossible, but not the easiest way to get started :)
We are currently experimenting with this approach. A good thing about paged.js is that we would be able to provide hot-reload and live preview of files without actually converting to PDF.
Your second point is very interesting, seems like some kind of .assert('text').isVisible() API. We may want to dig into that further!
We actually experimented with Gotenberg! Ultimately it is a layer on top of Chromium for conversion and we were dissatisfied with the results. I am curious so as to how are you handling assets and other static media / attachments: do you embed everything in a single HTML file or do you use some kind of bucketing system to resolve URLs?
Yes, we use an API layer on top of PrinceXML with additional polyfills to support modern features. This is a meh solution but it allowed us to iterate quickly and get to work with customers without building a full blown PDF engine firsthand. However building this engine ourselves is the key to reduced latency and overall better feature support. But we need to engage with our users first and see exactly where we should head first :)
Makes total sense. There is no real requirement to use Tailwind to create the PDFs, we just have grown accustomed to Tailwind :) If you don't use the <Tailwind> tag, the browser defaults are used to generate the PDF.
We quite agree on this - but getting a new alternative out will require a significant critical mass before it can be of any interest. While PDF has its challenges, it remains a light portable format and its security features make it a good fit for binding documents. The ecosystem, although it is dominated by Adobe, also includes other major players and existing integrations.
The way we look at it is PDFs allows embedding of other files and metadata. It is easy to provide a platform where we can enrich PDFs to display different contents than the one in the PDF itself. If this gets interesting enough, we can then phase out the PDF in the first place. But this is a long way ahead.
The pricing does go down for larger volumes and is something we still have to narrow down to the exact place that makes sense to companies and is also viable.
- We do not force PDF/* profiles down to the user, but it seems that for most of them PDF/UA-1 would be a sensible default. We can extract most of the tags from the HTML semantics by themselves which makes it much easier.
- We target the PDF 1.7 spec. Color profiles can be changed and you can use a custom .icc profile, with the corresponding embedding restrictions based on the document format. MediaBox is supported through the @page size property. Bleed, trim and marks can be added using vendor specific css properties. We don't support ArtBox yet but this is something we can look into! So far none of our customers really wanted to take this out to a real print shop, but we would be glad to help people go down this route :)