asciidoctor-web-pdf VS pandoc

I've been test-driving the web pdf build tool for Asciidoc, asciidoctor-web-pdf[1], for a few years, which uses Paged.js as the template engine before CSS PMM has its go. I like it - I like it a LOT[2] - but Puppeteer-Chrome bugs breaks the build on the regular, or requires a rework of templates. So the web-pdf team started just releasing docker images that include a tested Chromium version (among other things), so as to keep that from being such a PITA. Which is fine. Howaaaayyyyyyyver . . that shines a spotlight on a problem with this workflow: the dependency on browser rendering kit.

[1] https://github.com/ggrossetie/asciidoctor-web-pdf

https://github.com/ggrossetie/asciidoctor-web-pdf

I encourage everyone to take a look at the documentation; this is the markup language I now use for all my personal and professional projects.

https://github.com/ggrossetie/asciidoctor-web-pdf (this is an implementation of Paged.js +CSS for the Asciidoc markup language, as an alternative to asciidoctor-pdf [Ruby/Prawn] or asciidoctor-fopub [Docbook-XSL].)

We're currently ironing out the bugs for parallel AsciiDoc > PDF generation for downloadable/offline versions anyway, so once that's sorted we can use those for review again. Much as I hated writing book-style PDF help docs, Acrobat's commenting/review features are actually pretty hard to replace.

Asciidoctor-web-pdf https://github.com/Mogztter/asciidoctor-web-pdf for web-based PDF with Paged.JS and CSS.

You'll get extremely consistent output from Asciidoc, but I'm not gonna lie: customizing format is going to be a learning curve no matter what compared to MSO. Tweaking either 1) asciidoctor-pdf's yaml themes, 2) docbook-xsl overrides, or 3) asciidoctor-web-pdf's CSS and JS (via Paged.js Paged Media Module implementation). And if your parent org uses Office365 up and down the chain, Word publishing can be automated . . fairly well. You'll still get some surprises, but it's Word. It's the lingua franca for a reason.

How you turn including files into deliverables, there's a few paths, but HTML is the "natural" output, and PDF can be made with a few different tools depending on what the output format is required to look like. DocBook-XSL is a more complex but configurable processor, while the Ruby-based asciidoctor-pdf is the easier, more Honda-like option. I'm pretty fond of the "web-pdf" method (https://github.com/Mogztter/asciidoctor-web-pdf) which uses Paged.js and CSS to style the print document, but your mileage may vary depending on your CSS comfort level.

Asciidoctor has a web PDF tool that just went alpha a little bit ago, uses the same stack as the OP's thingie.

https://github.com/Mogztter/asciidoctor-web-pdf

The content handoff goes like this: Asciidoc (using defined roles) generates HTML5 (Pagedjs polyfills page areas / pagination stuff), CSS styles stuff, and Puppeteer runs a headless Chromium for the pdf render. It's straight from CSS GCPM W3C spec, a flavor of CSS Paged Media, drafts that have been percolating since frickin' 2006 but have never seen browser implementation.

Just use asciidoc.

E.g.

- https://github.com/Mogztter/asciidoctor-web-pdf/tree/master/...

My main authoring tool is then Emacs Markdown Mode (https://jblevins.org/projects/markdown-mode/). For data entry, it comes with some bells and whistles similar to org-mode, like C-c C-l for inserting links etc.

I seldom export my notes for external usage, but if it is the case, I use lowdown (https://kristaps.bsd.lv/lowdown/) which also comes with some nice output targets (among the more unusual are Groff and Terminal). Of cource pandoc (https://pandoc.org/) does a very good job here, too.

This is one of those things that the ever-amazing pandoc (https://pandoc.org/) does very well, on top of supporting virtually every other document format.

Folks feel the same way about Markdown versus LaTeX: why use something significantly more complicated where a looser, human-readable grammar works better?

For any other situations, I use https://pandoc.org/, or, generate a Word doc scriptomatically.

pandoc toolchain pour builder une version confortable/imprimable en phase de travail (ePub, pdf, docx, html)

Congrats on the launch, I guess, but there are so many free options that I can't think of a situation where paying $0.25 per document would be justified...? Just to name a few:

Back in the days, I used to use XSL-FO [0] and it was okay. It was not very precise but it rarely if ever broke, and was perfectly integrated with an XML/XSLT solution. Yeah, this was a long time ago.

Last month I used html-to-pdfmake [1] and it's also not very precise and more fragile, but very efficient and fast.

Yet another approach would be to pro grammatically generate .rtf files (for example) and use Pandoc [2] to produce PDFs (I have not tried this in production but don't see why it wouldn't work).

[0] https://en.wikipedia.org/wiki/XSL_Formatting_Objects

[1] https://www.npmjs.com/package/html-to-pdfmake

[2] https://pandoc.org/

Others have mentioned static site generators. I like Hakyll [1] because it can tightly integrate with Pandoc [2] and allows you to develop custom solutions if your needs ever grow.

[1]: https://jaspervdj.be/hakyll/

[2]: https://pandoc.org/

Have you compared it with a conversion by pandoc (https://pandoc.org/)?

I have used it to kickstart a blogging project that I wish to come back to soon. The Lua inter-op for custom readers, writers and filters is great but I wish there was more editor integration and even perhaps an official IDE/editor with built-in debugging features (probably something already do-able with Emacs but I haven't checked). The only blocker for my project is no support for "ChunkedDoc" for Lua filters [1] which forces me to write more code and a complicated Makefile.

[1]: https://github.com/jgm/pandoc/issues/9061