4 ms·

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

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 https://github.com/Mogztter/asciidoctor-web-pdf The content handoff goes like this: Asciidoc (using defined roles) generates HTML5 (Paged<dot>js 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. The beauty of this is that you use the same CSS for web and PDF deliverables. Actually, the even better beauty is that you are using two dirt-common technology stacks - CSS and Javascript - instead of XSL or Prawn or some ancient bespoke layout language. With Asciidoctor, for complex print requirements you're going to be forced to either 1) DocBook-XSL via fopub or 2) DocBook-LaTeX via dblatex. The native Prawn-based PDF tool isn't capable of a whole lot of customization without extensions. So web-pdf is a real shot in the arm for those of us that aren't real keen on going back into XSL-FO.

adamjhyde 6y ago
also using pagedjs :) awesome!
- MilStdJunkie 6y ago
  Yeah, in the Python world there's WeasyPrint for PDF out in the wild as well. It's quite slick, but it's a harder sell because of Python, which corporate types seem to think is bad hacker central. https://github.com/Kozea/WeasyPrint https://github.com/Kozea/WeasyPrint
gorgoiler 6y ago
Amazing news, thank you for sharing. Prawn’s pure ruby implementation of image layout makes it too slow for the graphics heavy technical manuals I write (though I haven’t used asciidoctor-pdf in 12 months.) I ended up drafting documents with 10dpi images just to get it to render quickly enough for layout but even then, adding images turned a 100ms render into a 6000ms render. Hopefully this problem goes away with a fast web based stack. I’ve never had much luck with break-after/before:avoid for <h2>. I hope their css or paged.js works for avoiding this common fault.
- MilStdJunkie 6y ago
  That's super interesting, I am in the same boat. Do you mind me asking what graphics format(s) you're using? We're using a sort of hybrid Asciidoc/S1000D approach, Asciidoc markup with S1000D architecture (filenamers, publication modules, data module codes, etc). The art is SVG brought over from CGM, with conditional content (applicability) controlling the images via a new module type we call "illustration control files" that toggle the art based on "applicability" aka asciidoc document attributes and ifdef/ifevals. PDF is via DocBook-XSL, but it's a scheduled process and not "on-click", which I am positive would break things. I am not even sure how to fire fopub from this company's web architecture; they wouldn't let us post html to a network directory (argh?), so any hopes of doing something more advanced are pretty low. In my off time I am looking at Antora pretty hard, and web-pdf is going to be the default pdf tool for that build platform. One thing I am wondering is how Antora's playbook files are going to relate to the "Ascii1000D" Publication Modules, which overlap a wee bit.

adamjhyde 6y ago

also using pagedjs :) awesome!

MilStdJunkie 6y ago
Yeah, in the Python world there's WeasyPrint for PDF out in the wild as well. It's quite slick, but it's a harder sell because of Python, which corporate types seem to think is bad hacker central. https://github.com/Kozea/WeasyPrint https://github.com/Kozea/WeasyPrint

gorgoiler 6y ago

Amazing news, thank you for sharing. Prawn’s pure ruby implementation of image layout makes it too slow for the graphics heavy technical manuals I write (though I haven’t used asciidoctor-pdf in 12 months.) I ended up drafting documents with 10dpi images just to get it to render quickly enough for layout but even then, adding images turned a 100ms render into a 6000ms render. Hopefully this problem goes away with a fast web based stack. I’ve never had much luck with break-after/before:avoid for <h2>. I hope their css or paged.js works for avoiding this common fault.

MilStdJunkie 6y ago
That's super interesting, I am in the same boat. Do you mind me asking what graphics format(s) you're using? We're using a sort of hybrid Asciidoc/S1000D approach, Asciidoc markup with S1000D architecture (filenamers, publication modules, data module codes, etc). The art is SVG brought over from CGM, with conditional content (applicability) controlling the images via a new module type we call "illustration control files" that toggle the art based on "applicability" aka asciidoc document attributes and ifdef/ifevals. PDF is via DocBook-XSL, but it's a scheduled process and not "on-click", which I am positive would break things. I am not even sure how to fire fopub from this company's web architecture; they wouldn't let us post html to a network directory (argh?), so any hopes of doing something more advanced are pretty low. In my off time I am looking at Antora pretty hard, and web-pdf is going to be the default pdf tool for that build platform. One thing I am wondering is how Antora's playbook files are going to relate to the "Ascii1000D" Publication Modules, which overlap a wee bit.