run headless chrome to render your web page to pdf
Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
61–70 of 94 posts
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#62Earlier quoted context omitted.
I dunno about that. 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…
TeX at this point has entered computing legend. It has such a long and storied life. 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.
What about https://typst.app ?
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#63Earlier quoted context omitted.
Please report back and let us know!
733 pages with the same cover image but without any calendaring line art comes in at 2049 KB. Opening that PDF back up in Chrome and using print "save as pdf" results in 1760 KB so there is some compression happening the second time around. Overall this looks very promising!
I would think that a PDF file of 700 blank pages could exceed 2 MiB.
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#64> 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. 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, jus…
As the maintainer of wkhtmltopdf @ Odoo I can tell you it's not WebKit. Instead it's outdated WebKit from 2014 running on top of QT4 '^^
@monax
Since you're the maintainer, I'll assume you no doubt will know more about it than me. But from what I (vaguely) recall, it's worse than that.
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?
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#65I have used Gotenberg [1] in a production environment. Dockerized in a Kubernetes Cluster. It just works! I can absolutely recommend it. Uses Chromium under the hood and was able to render gradients and text shadow, nice!
[1] https://gotenberg.dev/
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#66[deleted]
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#67@kelvinzhang
Quite frankly, htmldocs is the exact project i'm looking for months. I'm tired of word and same alternative and wanted something i can write html and css3 to convert to PDF.
You do and in a beautiful way !
Some question : i just want to use your product be also need to be sure my doc will by avaivable in futur. what's your plan ?
- opensource ? - community/enterprise ? - close source but a docker version to go on premise ?
Thanks for you answer and by the work very good works !
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#68See also native CSS support for paged media: 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 rea…
I dunno about that. 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…
Once I had the chance to move away from Word, TeX was the first place I went. That said, I eventually tired of the obtuse error messages and felt I was making things more complicated for no real gain.
Even keeping a BasicTex environment working requires effort that HTML does not.
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#69Weasyprint has a bunch of options to do almost anything you can think of, but in my case, it's just a generator.
To your point that htmldocs supports more modern CSS features, I can see the advantage. Although the most complicated things I needed - aside from @page rules - were a replacement for a 2nd page header (solved w/ Flexbox) and automatic page breaks that would display correctly (a few lines of CSS processed w/ Weasyprint came out better and didn't require me to print to PDF manually.)
Re: Show HN: Htmldocs – Typeset and generate pdfs with HTML/CSS
#70Earlier quoted context omitted.
Interesting, I'm looking for a solution to render PDFs at the moment, it looks like that one actually does not use chromium, unlike most tools that I've seen that render HTML to PDFs. What's the advantage? Is it more lightweight / faster / reliable?
We actually ran off of WeasyPrint at first but switched to Chromium due to emojis not rendering properly, poor flexbox support, no custom fonts, and other differences between the HTML you'd see in a browser vs. the generated PDF. WeasyPrint 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 bett…
Flexbox support has been [included][1] since 2018, although my use case was the prototypical one - a single row w/ 3 columns - so YMMV with how it handles more complex layouts.