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?
We offer comprehensive import/export functionality, ensuring seamless transfer of reports between environments. Moreover, workspaces allow you to segregate test and production environments or create unique environments for each client, allowing easy report customization. While reports are simply JSON files, which could theoretically be stored on the file system and checked in, doing so would hurt the flexibility we're trying to achieve.
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
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 :)
Thanks for the perspective. Indeed, this is an area with real demand. I haven't evaluated YC's recent startups but I trust they do know a bit about what has a better chance in the market. Best of luck :)
ps.: As someone with very minimal PDF needs personally and at work, I'd say the beautiful templates are what caught my attention the most.
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.
