Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS (htmldocs.com)
I built this because I wanted to programatically generate invoices as well as automatically tailor my resume to jobs but had no good way of generating well-formatted PDFs. I ended up building a templating engine to Chromium rendering pipeline to generate PDFs, and due to the amount of engineering effort, turned it into a tool for others that might want to do the same. There's a built-in API (https://htmldocs.com/docs/documents) that you can call to turn JSON into PDFs in a single call.
htmldocs is different from other tools like Wkhtmltopdf and Weasyprint in that it uses Chromium to generate PDFs, meaning that it supports the most modern CSS features and there's minimal drift between the rendered HTML document and PDF.
Will also consider open sourcing if there's enough interest in the project!
93 comments
[ 4.5 ms ] story [ 180 ms ] threadWeasyPrint implements its own rendering engine and might support some specific @page properties that Chromium does not but given the complexity of CSS and web browsers, you're generally better off sticking with Chromium due to its history.
Also – an added benefit is that we can use JS libraries like FontAwesome, Bootstrap, KaTeX, etc. which is where other HTML to PDF libraries fall flat.
[1]: https://github.com/Kozea/WeasyPrint/pull/579
https://www.quackit.com/css/at-rules/css_top-center_at-rule....
[1] https://wkhtmltopdf.org/
[0] https://blog.horaceg.xyz/posts/resume/
[1] https://github.com/typst/typst
WeasyPrint is implemented as a from-scratch and specific-purpose rendering engine, so yeah, it’s different. But wkhtmltopdf uses WebKit, meaning it’s much the same as htmldocs, just backed by a different browser engine.
It’s important to realise, though, that using an existing browser engine doesn’t mean everything’s hunky-dory: in fact, when it comes to some of the things you care about with producing PDFs, some things will be worse, and the WeasyPrint approach has significant advantages. Because browsers don’t care about your use case at all. From time to time they’ll improve things incidentally, but all browsers are missing things like a lot of CSS Paged Media stuff, stuff that’s often been specified for a decade or more, where things like WeasyPrint have had them for years and years.
Not at liberty to elaborate on exact details, but not so long ago I had to deal with wkhtmltopdf, when it turned out to be the (still preferred/recommended) PDF rendering solution as part of a major popular web middle-ware framework, at a large corporate client. I was rather shocked to see a top-tear prestigious international institution working with such outdated tech (albeit certainly in ignorance), but never mind that.
What struck me most was the nature of the bugs I encountered. Probably one of the most baffling: seemingly randomly changing formatting of the output. In the end it turned out to be a Windows specific problem, where multiple administrators logged onto the Windows Server hosting the web application. Because of different workstation display geometries on their end, they effectively kept changing the display DPI settings of that server (a headless machine, only accessed through RDP). That in turn affected the rendering internals of wkhtmltopdf. Rather hilarious when I finally figured it out. That's when I learned it best never again use wkhtmltopdf on any Windows system (if anywhere at all, for that matter).
Wasn't the WebKit core even older than 2014? Maybe something about it being older but then just maintained independently until 2014 .. or something like that? Or maybe my memory is just messed up and failing me.
Either way, what I do remember is my amazement about seeing this (at best) 10 year old code (arguably of questionable quality to start with and certainly outdated by now) still in use as a go-to solution for rendering PDF from HTML. Ended up replaced it with a puppeteer-based solution. Arguably with its own problems, but less of a black hole than wkhtmltopdf. Especially considering it was (also) rendering user-supplied data. What could ever go wrong, right?
I find the bug you mentioned interesting, and I'll promptly investigate to determine if it still exists. If I remember correctly, there's a --dpi option that may have already resolved this issue.
I share your concern about the code's state; it's problematic as it's currently leaking file descriptors and memory all over the place. We experimented with Puppeteer as an alternative, but its speed and memory usage were too high for our specific use case, so we're currently stuck with the current wkhtmltopdf.
I'm not even concerned all that much about the code's state itself, rather that it still shows up today. In situations it was probably never designed for. Adding to that, it now often appears wrapped inside some interfacing layer/code, binding it to whatever other software it is embedded in. But then only exposing part of wkhtmltopdf. Case in point, the --dpi option you mentioned (which indeed might fix the mentioned bug), was simply inaccessible through how the framework interfaced with wkhtmltopdf (which was a design cluster-F# in its own right).
However, the bigger elephant in the room for me is that the HTML/CSS support has changed considerably over the last decade, with wkhtmltopdf pretty much stuck in time. It's just pretty much a random hit or miss when it comes to rendering any modern web content. Only for carefully crafted (legacy) content does it still make a good use case.
I won't blame wkhtmltopdf for that though, but I sure haves questions for those who apparently still consider it a valid tool for integration into modern web frameworks. I guess part of that comes down to unintentional ignorance, not knowing what they are actually integrating. Another reason might be that I've not seen much of a better sort-of-drop-in replacement for wkhtmltopdf, so people stick to it far a lack of a proper alternative. Maybe some of the people who integrated wkhtmltopdf elsewhere are even very well aware of all the limitations/dangers. Still, little use of that if that knowledge is lost on those who subsequently end up using it, primarily just as consumers.
Puppeteer is a very different beast in its own right, regardless which engine/browser you end up using. But if more modern html/css features are required, it can be a valid replacement (regardless of numerous downsides nonetheless). Still, I (also) doubt that it will work as a good replacement for all of wkhtmltopdf's use cases.
If nothing else, I got some free entertainment out of it all .. watching the shocked expression on the faces of top-level suits, when I explained to them what they had been blissfully unaware of. They had good reasons to be worried, because this exposure should have been caught by their rigorous technology-review procedures. However, it had been an ad-hock dependencies that was introduced as part of a legit feature request. The dev had probably never even noticed, because it appeared as a native framework functionality (hiding any obvious reference to using wkhtmltopdf under the hood). Anyways, wkhtmltopdf is certainly not to be blamed for that.
Still, it does illustrate the dangers of modern-day software integration. I think especially in (web) frameworks, where the name of the game often appears to have turned towards a popularity contest (with competing frameworks) and "making things as simple as possible". Something about a road paved with good intentions.
> You acknowledge that the Website is a general-purpose search engine and tool. Specifically, but without limitation, the Website allows you to search multiple websites for music. Moreover, the Website is a general-purpose tool that allows you to convert audio files from videos and audio from elsewhere on the Internet. The Website may only be used in accordance with law. We do not encourage, condone, induce or allow any use of the Website that may be in violation of any law.
TOS is pretty general and just there for legal reasons, tl;dr feel free to use as you see fit as long as it's not for anything illegal.
https://playground.jsreport.net/
I also just open sourced part of my app that does PDF generation, but it’s completely bare bones.
I basically wanted a wrapper around the pdf generating part of chromium so that i could generate pdfs on pages within my own app.
Its here if anyone wants to check it out: https://github.com/awongh/bakso-doc
"Typeset and Generate PDFs with HTML/CSS"
really should be the H1 on that page for clarity.
But
could use some performance improvements...
Maybe you tested this on your state of the art workstation but my i7 8th gen is getting choked to death...
EDIT:
It doesn't seem to work: I picked the resume template and set the margin and padding on `li` to 0 but nothing changed in the output.
- having a web editor interface without needing to re-run a CLI command
- people who don't want to deal with packages/dependencies on their own system
- users that just want an affordable and easy-to-use API to generate PDF documents instead of having to set up their own server <> task queue <> worker system which would usually cost more
- in the future, teams that want to collaborate together on a document
Its fun and fast to generate things but when you get to 1000+ pages for something like a year long planner the document can quickly balloon past 70 MB.
So far I have kept my 750-1300 page planner between 3-7 MB.
I will give this a try and compare.
Overall this looks very promising!
I had a similar itch to scratch and I found quarto (https://quarto.org/) - free, open-source and doesn’t depend on chrome (admittedly it has other dependencies, but at least not chrome).
But I'll be giving this a try!
https://www.w3.org/TR/css-page-3/
When I looked into it several years ago, browser support for some critical features wasn't there yet. Not sure whether this has improved.
In principle, this would be a great alternative to proprietary PDF rendering libraries which require you to design your document completely in (e.g. Java) code, and to the typical LaTeX approach. You really appreciate the elegance of HTML+CSS once you had the misfortune of having to do a simple fucking table in LaTeX.
For simple stuff, sure HTML and CSS is great, but when I want something print-perfect I use LaTeX.
A simple table in LaTeX is no harder than in HTML, assuming the same level of knowledge in the tool.
But then when you throw in a simple requirement like "left margins on even pages and right margins on odd pages need to be larger", HTML becomes hell to work in.
HTML and CSS, even with a media query for print, sucks.
I mean, I'm not creating pages with `<page>...</page>`.
https://developer.mozilla.org/en-US/docs/Web/CSS/@page
https://developer.mozilla.org/en-US/docs/Web/CSS/page
But it’s old. We need something modern, that represents current ways to make documents from code. And that way is CSS. I bet within my lifetime most scientific publications will move to a PDF tool that ingests CSS. We just need to find something open-source and clean that has no missing functionality.
I'd love something newer than TeX/LaTeX. Something with consistency (is it \$CMD{...}, \begin{$CMD}...\end{$CMD} or \{$CMD ...}?), better error messages, more specific and targeted warnings (most hbox-full warnings can be ignored, but many can't!), support for specifying `-Werror` (like gcc) and other things like that.
> I bet within my lifetime most scientific publications will move to a PDF tool that ingests CSS.
Maybe[1]. CSS and HTML needs a lot more functionality though. They have no page counter, no chapter counter, section counters, etc. No river detection, run detection, orphan detection, etc. No automatic reference manager[2], no automatic referencing of chapters, sections, tables, figures, etc. Missing correct hyphenation breakpoints.
Additionally, some things are there, but in a poor (for typesetting) way - inter-paragraph spacing must be faked (no, `:after` isn't a good way to specify `inter` spacing), no way to prevent what should be an atomic element (say ... an mbox containing a paragraph and an image) being broken across pages, no way to float an element to the next point in the document where it will fit (LaTeX does this by default, and it annoyed me no end when I could not find a way to get HTML documents to stop breaking my pretty short table across a page, and instead just place it on the next page).
Another thing that I think are a poor fit, but others think are superior, are the scripting facilities for creating new commands: doing `\newcommand or \newenvironment` is a lot less friction than doing an entire custom element. It's so little friction, that for an invoice I can simply do `\newcommand{\client}{\textbf\emph{The Client PTY LTD}}` and then use `\client` everywhere in the document.
I'm looking forward to a new LaTeX/TeX that fixes all those things. Maybe CSS+HTML would eventually get them, but many of those things are table stakes for typesetting, and yet they are not even on the horizon (or roadmap) for CSS+HTML.
[1] Could be I'm wrong. Like I said in another response, I'm no expert in CSS or HTML. [1] This can be easily resolved with a custom web component
> And that way is CSS. I bet within my lifetime most scientific publications will move to a PDF tool that ingests CSS. We just need to find something open-source and clean that has no missing functionality.
Looks like it. I'm pretty sure most of the things you mentioned are either already possible or in the paged media spec / covered by paged.js.
Even keeping a BasicTex environment working requires effort that HTML does not.
The error messages are pretty poor.
> Even keeping a BasicTex environment working requires effort that HTML does not.
I've been told, by Mac and Winodws users, that it's a pain.
Personally I've never had to download extra packages/styles directly on Debian. Performing `apt-get install tex-<whatever>` normally installs everything (where `<whatever>` is something I find from a search in synaptic).
I think you’re onto something here.
I work on an OSS reporting and analytics tool (https://github.com/evidence-dev/evidence) and the amount of time and effort that goes into a really good “print pdf”, and how valuable people find it, has been one of the more surprising parts of the project to me.
One small thing, when signing up with Gmail, it still asks for my Name and Surname when supposedly it's something you can get out of the OAuth APIs.
Any suggestions on a web solution that allows non-devs to make great templates would be appreciated.
Historically I've built something simple with Tiny and added a preview button to render, but that super clunky.
[1] https://github.com/flyingsaucerproject/flyingsaucer
For those interested in giving it a try, please contact us at support at cx-reports dot com. We are providing complimentary licenses to users who are eager to collaborate with us during this phase.
Screenshot: https://pasteboard.co/th5f4s0uVWJH.png
Thanks for your long lived contribution.
> htmldocs.com has not completed the Google verification process. The app is currently being tested, and can only be accessed by developer-approved testers. If you think you should have access, contact the developer.
What I like about Typst is that I can use it completely offline and with my editor of choice. Is this planned for htmldocs too?
[1] https://typst.app/
Typst is great but there are a few key differences:
- full CSS support, allowing for more customizability and familiar styling without a learning curve
- less tailored towards academic use-cases are more towards personal/business use-cases like resumes, invoices, reports. Also adding a template gallery in the near future.
- has a templating engine and API baked in
- can use JS packages and ecosystem (ex. icon sets, fonts, etc.)