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

21–30 of 191 posts

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

#21

Post by Titou325 »

matteason wrote: post #15

Really interesting product. I do agree that the pricing seems steep ($0.25/document on Pro on the most generous tier) but I don't know enough about pricing B2B products to know if that would be a blocker. I agree that HTML -> PDF can be a really powerful tool. I worked on the UK government's tool to generate energy efficiency labels for consumer goods [0] and we ended up doing PDF generation with SVG templates, using…

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

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

#22

Post by dazh »

Glad to see people building in the PDF space, which as a format is unfortunately both awful and ubiquitous. Are you planning to build any support for programmatically filling out existing PDF forms? That's a huge pain point our product is facing that doesn't seem easy to solve.

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

#23

Post by Crowberry »

Leoko wrote: post #16

I had to deal a lot with PDF generation over the past few years and I was very unhappy with the eco-system that was available: 1. HTML-to-PDF: The web has a great layout system that works well for dynamic content. So using that seems like a good idea. BUT it is not very efficient as a lot of these libraries simply spin up a headless browser or deal with virtual doms. 2. PDF Libraries (like jsPDF): They mostly just ha…

I'm with you..

We ended up writing a similar wrapper around https://github.com/jung-kurt/gofpdf library. We haven't open sourced it yet. But it's made it a lot easier to deal with rendering a PDF, especially over pagebreaks ect.

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

#24

Post by cratermoon »

The problem with using Tailwind is that I can't just say Some Heading. As noted in the Tailwind documents "All heading elements are completely unstyled by default, and have the same font-size and font-weight as normal text."[1]

Most of the time when I'm writing HTML I want a set of default styles for the most common elements, It's tedious and error-prone to have to specify a class every single time.

1 https://tailwindcss.com/docs/preflight

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

#25

Post by Titou325 »

ramon156 wrote: post #17

Can we not have an alternative to PDFs? I get that they're more standardized but why would everyone let adobe have the hammer for a file type that's so important

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.

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

#26

Post by pedro120 »

Crowberry wrote: post #20

This looks really interesting! One of the main reasons we've opted to writing a more complex rending code is for speed. We're getting around 500ms for a single document, which is (last I tested) quicker than any headless chrome setup. How long does it take to render using your API? :)

Rendering time scales with the length / complexity of the document. At the moment, our self-serve API renders slower than a headless chrome setup. We are working on speeding this up as it is currently in the order of seconds.

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

#28

Post by Leoko »

Crowberry wrote: post #23
Leoko wrote: post #16

I had to deal a lot with PDF generation over the past few years and I was very unhappy with the eco-system that was available: 1. HTML-to-PDF: The web has a great layout system that works well for dynamic content. So using that seems like a good idea. BUT it is not very efficient as a lot of these libraries simply spin up a headless browser or deal with virtual doms. 2. PDF Libraries (like jsPDF): They mostly just ha…

I'm with you.. We ended up writing a similar wrapper around https://github.com/jung-kurt/gofpdf library. We haven't open sourced it yet. But it's made it a lot easier to deal with rendering a PDF, especially over pagebreaks ect.

Yes, page breaks are probably the most significant difference between the layout of a web page and a PDF document, and thereby a major drawback when using HTML-to-PDF. There is little to no tooling for this in the web.

If you want granular control over how your PDF will look with content that is more than one page long, you will have a hard time using html.

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

#29

Post by Titou325 »

cratermoon wrote: post #24

The problem with using Tailwind is that I can't just say Some Heading . As noted in the Tailwind documents "All heading elements are completely unstyled by default, and have the same font-size and font-weight as normal text."[1] Most of the time when I'm writing HTML I want a set of default styles for the most common elements, It's tedious and error-prone to have to specify a class every single time . 1 https://tailw…

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 tag, the browser defaults are used to generate the PDF.
Post reply on HN