Titou325

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

Yes, Onedoc generates tagged PDFs as long as you add a `title` property to the API call to make the PDF UA/1 compliant.

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?