Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Onedoc (YC W24) – A better way to create PDFs

github.com

Post reply on HN
Print view View original

131–140 of 191 posts

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#131

Post by cpr »

Titou325 wrote: post #34
cpr wrote: post #14

So are you using PrinceXML for your "completely separate engine where typography is a first-class citizen"?

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 shoul…

Isn't PrinceXML pretty much up to date? What's missing?

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#132

Post by ska »

rahhulk7 wrote: post #117

This looks interesting! Especially the Markdown and LaTeX components in react-print-pdf. Could be a great way to streamline technical documentation generation in codebases. Would love to see some examples of those in action.

FWIW I’ve had some good results for technical documentation in RST markdown with sphinx for generation. You can develop latex header details for detailed templating for pdf output, etc. while keeping the html more simple if you want .

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#133

Post by egnehots »

AugusteLef wrote: post #130
plopz wrote: post #127

Earlier quoted context omitted.

The problem with chrome is the performance, it is very slow and uses a bunch of memory. There was a neat post here awhile ago about generating pdfs faster https://news.ycombinator.com/item?id=39379690

Indeed, speed is an issue (and it's hard to tackle). Additionally, when using Chrome, what you see is not always what you get. The layout often doesn't match expectations, especially with complex elements. It's ok for simple use cases, but for professional and scalable solutions, you usually need to switch to something else!!

Yes, that's a hard issue for arbitrary/user-provided HTML pages. But with templates under your control, the context is different. Your designers do not have to trust Chrome; they can preview, tweak using print media queries, and provide robust templates that print to acceptable PDF.

The speed issue is also real, but you can scale horizontally by spawning other chromium instances (with gotenberg containers for ex). Not really efficient but it can certainly help alleviate most of the load...

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#134

Post by AugusteLef »

egnehots wrote: post #133
AugusteLef wrote: post #130

Earlier quoted context omitted.

Indeed, speed is an issue (and it's hard to tackle). Additionally, when using Chrome, what you see is not always what you get. The layout often doesn't match expectations, especially with complex elements. It's ok for simple use cases, but for professional and scalable solutions, you usually need to switch to something else!!

Yes, that's a hard issue for arbitrary/user-provided HTML pages. But with templates under your control, the context is different. Your designers do not have to trust Chrome; they can preview, tweak using print media queries, and provide robust templates that print to acceptable PDF. The speed issue is also real, but you can scale horizontally by spawning other chromium instances (with gotenberg containers for ex). No…

Absolutely! It's all about finding the right balance between granting users complete control over the layout and restricting it to ensure specific use cases through templates. As for scaling, indeed, horizontal scaling is an option, but there's a limit to its practicality. It would be interesting to conduct a resource/time analysis over the various solutions available on the market in different situations/use cases

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#135

Post by AugusteLef »

ska wrote: post #132
rahhulk7 wrote: post #117

This looks interesting! Especially the Markdown and LaTeX components in react-print-pdf. Could be a great way to streamline technical documentation generation in codebases. Would love to see some examples of those in action.

FWIW I’ve had some good results for technical documentation in RST markdown with sphinx for generation. You can develop latex header details for detailed templating for pdf output, etc. while keeping the html more simple if you want .

Thanks for the tip, I will take a look at it asap

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#136

Post by adfaure »

yencabulator wrote: post #124
egnehots wrote: post #102

The main issue is conflating templating and pdf generation. Using html to pdf solutions allow to do the templating in html, where it is pretty much a solved issue. And as many said, headless chrome is a robust html to pdf solution, even though it feel like a hack. But, yeah, there seems to be a lack of awareness about these options within corporations. So, kudos to you for addressing a genuine problem!

Typst is a typesetting language that makes programmatic layout and processing JSON input pretty darn simple. I make invoices by having a Typst template read line items from a JSON file. https://github.com/typst/typst

Just spent my Sunday creating my invoice template in typst as well. I enjoyed it, and I could do what I wanted quickly!

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#138

Post by cyanydeez »

rudasn wrote: post #123
Titou325 wrote: post #48

Earlier quoted context omitted.

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!

Or maybe some visual diffing based on expected output, based on the template/layout/theme used, since you'd want to perform this check on every pdf generated in prod (that has real, sensitive data) , not just in CI or testing mode, if you're aiming for critical docs. Cool project btw, congrats for the launch!

safer would be out of band pdf-image conversion the OCR

WHen dealing with layouts and assurance, I would go way out to verify as close to print as possible.

there's also a discussion about color to black/grayscale printing where you want a document to stay in character at grayscale.

these would be premium features I'd think.

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#139

Post by AugusteLef »

axhl wrote: post #137

neat. are there similar services / libs for generating word docs? this is a recurring problem for many

We do not work with docx and never did it myself but: "DOCX Template API is a tool that allows you to dynamically generate MS Word documents by replacing custom properties using a JSON object that contains your data." I assume this is more or less similar to what you are looking for (?)

Re: Launch HN: Onedoc (YC W24) – A better way to create PDFs

#140

Post by axhl »

AugusteLef wrote: post #139
axhl wrote: post #137

neat. are there similar services / libs for generating word docs? this is a recurring problem for many

We do not work with docx and never did it myself but: "DOCX Template API is a tool that allows you to dynamically generate MS Word documents by replacing custom properties using a JSON object that contains your data." I assume this is more or less similar to what you are looking for (?)

Yes - sadly the pricing and docs aren’t the most competitive or intuitive. Hoping someone in the thread has experience with alternatives. Very best of luck with your launch
Post reply on HN