Created by three friends who were frustrated by existing solutions and wanted to make PDF creation easier for everyone. Now it’s yours. What are your thoughts on it ?!
Are there any demo pages where it is possible to view the generated PDFs? I would imagine this would be easier to do since this is all based on Javascript.
For the generation we have an API that you can use npm @onedoc/client which allows you to do unlimited rendering with watermark, and some without the watermark to a certain limit. But you are also free to use any other software or API allowing this (PrinceXML is one of them. In our case we directly convert the bundle HTML/CSS to PDF and have 100% accuracy over the layout conversion (compare to chrome solution for example) as the open-source library react-print-pdf has been design to do that.
About the demo page, 2 choices if you use Onedoc API. 1. you can render your PDF and write it directly in you local machine --> so you can open it on your editor (VScode or whatever) and have side by side the code and the preview 2. you can render the PDF and host it on our cloud platform. You'll get a link to share it with others and you will also be able to preview it directly from our webapp.
Here is some links: API: https://www.npmjs.com/package/@onedoc/client Onedoc App: https://app.onedoclabs.com/login Documentation: 1) react-print-pdf https://react.onedoclabs.com/introduction 2) onedoc API: https://docs.onedoclabs.com/introduction
I hope it helps. let me know
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.
The only open source alternative I know of is WeasyPrint at https://weasyprint.org/. I'm not sure how well it fares against PrinceXML, though.
And thanks for the pointer to Taffy - I didn't know it before!
- use a React SSG, obviously without client-side code
- use an existing "print to PDF" engine to render the resulting HTML+CSS
At first glance, this seems to be using JSX only. Ain't it possible to use JSX and fully static components without even using React? Is that what Astro is doing?
I'm a bit underinformed here, but it would be nice if the landing page would outline a bit more clearly what parts of React are used here and how (it also mentions fetching data dynamically to feed the components).
The PDFs hopefully don't contain JS interactivity and the data fetching is done at the top level of the component tree, before rendering the result to HTML (or does this skip HTML+CSS as an intermediate completely?), right?
The landing page looks great, would just love some more thorough explanation on what parts of React this uses and how.
Also, is there a JSX-based SSG that completely excludes client-side JS and is not made by Facebook? Would be interesting.
All that being said, it's truly interesting how much appeal JSX still has as a templating language focusing on JSON-serializable data structures, completely ignoring React's original value proposition of reactivity.
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!
Sounds like React JSX rendering while omitting any client-side JS could benefit from forking off React itself, no?
OTOH it's up to the user of course to choose components that do not require client JS and diagnose problems caused by components relying on it.
