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 support the size[1] property and the widows and orphans[2] spec for both your needs :)

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/@page/size [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/orphans

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?

We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak

CSS actually implements the break-before property to control this https://developer.mozilla.org/en-US/docs/Web/CSS/break-befor... which is also supported by the Print to PDF dialog in modern browsers.

We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak

CSS actually implements the break-before property to control this https://developer.mozilla.org/en-US/docs/Web/CSS/break-befor... which is also supported by the Print to PDF dialog in modern browsers.

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 :)

We use a dedicated HTML to PDF engine (such as PrinceXML) rather than building on top of a browser. Main issue with browser-backed implementations is that PDFs are often of subpar quality. However, the main good thing is you can rely on the latest CSS features.

In the end, what was the main decisive factor is the support for the PrintCSS and PagedMedia specifications, which have been completely discarded by major vendors and only implemented by specific engines.

There is both commonalities and differences! Both approaches rely on web technology to provide the layout and are flexible in terms of frameworks and integrations.

Where things differ is that we don't actually use a browser under the hood. This allows a much better control over typesetting and layout - and you can do it on the server. We have also more controls over the outputted PDF and the ability to use more advanced features such as form fields or embedding other files and metadata in the PDF.

It definitely is! Typesetting quality was the main reason we chose not to go down the Puppeteer/headless browser route but rather use a completely separate engine where typography is a first-class citizen.

We like LaTeX, but even for advanced users laying things out can be a difficult thing. Given that documents are a frontend, we wanted to bring the same tools frontend developers already use.

This is a good point, and we are still trying to figure out how to price things fairly. Depending on the type of PDF, whether it is a simple receipt or a large multi-pages report, associated costs are very different on our side. At this time, we rely on other proprietary software that we are aiming to replace but that incur high costs on our side as well.

Edits and corrections on generated PDFs is not provided as the PDFs are signed as-is, however you can attach the metadata to the PDF and rerender with the modifications.

We are using a wrapper around PrinceXML until we can move into a separate rendering engine. We want to be able to offer the same layout features of such an engine, hopefully much faster.

You can have a look at our (WIP) set of templates at https://react.onedoclabs.com/ui/templates where the images are automatically built from the PDFs themselves.

We are trying things out to see how we can make a live preview for development purposes but the challenges of pagination are quite hard to solve in an elegant way at the moment. We are experimenting with Taffy to see how it could fit our use case but this is still a very early tentative.

It could probably but I believe maintaining these two would probably be more work than accepting the drawbacks. Another advantage of supporting full-fledged React is that (in the near future) we can allow Javascript in the rendering engine, meaning that components can recompute themselves and pull their own data in. We will see where that goes!

Hey, Titouan part of the Onedoc team.

You are absolutely correct and most existing tools do leverage a browser (sometimes headless) to convert HTML to PDF. However, browser's CSS print specification implementation is severely lacking and layout options are poor to say the least.

There is a second option using libraries that abstract part of the layout process such as react-pdf but although it uses the JSX syntax, you can't port existing HTML components easily.

Onedoc is able to take HTML + CSS as well, quite similarly to what you can do with Resend. React is mostly an abstraction layer that allows you to take advantage of all the existing SSG toolset (e.g. charts, existing frontend components, ...) without having to write things from scratch. The process is thus indeed similar to Astro if you omit any client: directives.

We have put up a small comparison at onedoclabs.com/why-onedoc to show a bit better what capabilities this opens.

Hope this clarifies things!

Hi! We are the team behind Onedoc, an easy way to generate and manage documents for developers.

We experienced the problem first hand creating hundreds of personalised marketing materials and working with various clients: PDF is broken. But it is still needed and we wanted a better way to handle it.

We are launching Onedoc after pivoting away from the AI space, and would be glad to hear what you think is right or wrong with this approach!