3 ms·

I just laid out a book using Pagedjs.org. Although there were a few bugs in the preview experience, the final output was perfect, and probably took me a quarter

I just laid out a book using Pagedjs.org. Although there were a few bugs in the preview experience, the final output was perfect, and probably took me a quarter the time it would have in InDesign (which I’m fairly competent in). The real power is in being able to hook up all the templating, CMS APIs, and whatever else you want into your content pipeline. It’s Just HyperText™. I’d go so far to say that if you’re equally comfortable in HTML/CSS and InDesign, Pagedjs is a superior choice for long form layout.

yawnxyz 3y ago
I’ve designed and printed many conference abstract books with PagedJS! Love that thing
strogonoff 3y ago
I wonder how the finer issues of typesetting are handled with print CSS compared to dedicated typesetting software nowadays. CSS is very compelling, but then based on my personal experience as print media designer the likes of InDesign are full of various special tricks (and language-specific, too) for alleviating white space corridors, handling hanging punctuation, hyphenation, etc. that the enterprise-level software tends to accumulate (due to the business model if nothing else).
- sings 3y ago
  It is limited and depends on the browser used to print the document. The most glaring missing feature is CMYK colour. I’ve just set up our publications to use PagedJS, and with a fair amount of hacking I was able to set up a baseline grid. Hyphenation depends on the browser implementation, which is OK for English in recent Chromium. The new text-wrap property has also been helpful. Hanging punctuation is only supported in Safari if I remember correctly. But being able to produce nice looking PDFs from a markdown document, with automated endnotes and table of contents, is a much nicer process than going through InDesign, and I also say this as someone equally comfortable with both. And the result is good enough for our purposes. Here is an example: https://www.lowyinstitute.org/sites/default/files/2024-03/LAVEIL-Papua-New-Guineas-fiscal-decentralisation.pdf https://www.lowyinstitute.org/sites/default/files/2024-03/LA...
  - strogonoff 3y ago
    I agree that InDesign generally is clunky (the same reason it has a lot of typesetting black magic: business model where you make money by satisfying requests of perfectionist designers and their managers). However, in the past, while I was still doing relevant work, I had mild success abstracting some of it out by defining a template and populating it with data imported from JSON. Now I’m not using ID much, and struggling with generating PDFs from HTML, so I really appreciated the example you gave. Great work!
- dylan604 3y ago
  The lack of manual kerning to avoid rivers of white space is something that I wouldn't even begin to know how to tackle in CSS. Maybe I'm just too muscle memory familiar with the tools in DTP vs CSS for Web, that I'm just not familiar with the proper CSS for it. The wysiwyg of DTP apps is like pure training wheels or a warm fuzzy blanket in getting work done
  - strogonoff 3y ago
    A large amount of   and spans with letter-spacing or font-kerning can help, but no one’s going to do that (unless you go for an extremely fixed layout or engage JavaScript, which I would consider in poor taste for these purposes). I concur on the warm fuzzy blanket of DTP software, personally.
    - dylan604 3y ago
      exactly. that sounds like a pretty good description of hell to me. i much prefer highlighting the text, alt/option-left/right to adjust the kerning in real time. this type of description of using CSS for DTP reminds me of using tables for layout before CSS. it was a bullshit solution waiting for something better. only, in this case, DTP software is already there and better. so why would someone do this to themselves?
      - strogonoff 3y ago
        I imagine to avoid paying expensive license fees, to stick with OSS out of principle, and/or to implement various fun integrations.
        dylan604 3y ago
        oh to be young and a dreamer. now, i just want to get work done with the most efficient tool for the job. that kind of hell is for the young
        strogonoff 3y ago
- delhanty 3y ago
  > but then based on my personal experience as print media designer the likes of InDesign are full of various special tricks (and language-specific, too) That seems to concur with an informative article by AtaDistance from 2019 that I read the other day [0]: > ... > The result was InDesign 1.0 J which shipped in early 2001. InDesign J was the first, and only, major software application developed outside of Japan that followed the Japanese Industrial Standard (JIS) X4051 typesetting and composition specification (the kumihan “bible”) and traditional Japanese print production methods. > I have covered some basics of Japanese layout before, but a review is helpful for first time readers. I’ll use a mix of my material and McCully’s presentation to explain. > ... > Western created DTP layout is graphics-driven and calculated by margins and font baselines. The western baseline typography model and font metrics is how PostScript and OpenType fonts, and all layout engines evolved. Adobe was well acquainted with the shortcomings of their own font technology and InDesign J got around the problems by adding proprietary Kanji virtual body font metrics and Japanese line break algorithms. None of this exists as an open standard that benefits everybody. > That is fine for InDesign and print production, but web layout and typography via CSS is an entirely different world. There are 3 huge obstacles for good vertical Japanese typography on the web: > * No font metrics for virtual body/em-box glyph space placement: everything has to be accomplished with baseline metrics > * No reliable space control > * No reliable line breaks [0] https://atadistance.net/2019/04/26/the-state-of-css-japanese-layout-open-type-variable-fonts-and-why-apple-news-wont-happen-in-japan/ https://atadistance.net/2019/04/26/the-state-of-css-japanese...
  - strogonoff 3y ago
    This brings me back to when I did a gig typesetting a Japanese language book (short, maybe couple dozens of pages) once. I don’t even speak Japanese all that well, the guy basically looked for someone with IDJ (which I had coincidentally) and basic skill to operate it. The software handles most of the magic. As a designer, I won’t pretend I didn’t feel a little used.
MilStdJunkie 3y ago
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[3]: the dependency on browser rendering kit. [1] https://github.com/ggrossetie/asciidoctor-web-pdf https://github.com/ggrossetie/asciidoctor-web-pdf [2] Asciidoc has four major PDF pipelines in some form of maintenance. The vanilla, asciidoctor-pdf, is a Ruby-based Prawn PDF generator, and it's good but limited in terms of layout - you end up having to extend the core Asciidoctor processor for a lot of tricks like LoT/LoF. Asciidoctor-pdf, and I really want to emphasize this, is the official PDF pipeline for adoc files. The older pipeline, FOPUB, is based on DocBook, which Asciidoc has equivalency with. But DocBook means XSL, and XSL means cheating on Russian roulette because just one out of six chance of ENDING THE PAIN is not enough. The odd man out is DBLATEX, which goes Asciidoc->DocBook->LaTeX-> PDF, and . . whew, ok man, you're jumping three markup languages, dude. Other than that, LaTeX is pretty much the gold standard for layout markup. Finally, we got this thing, asciidoctor-web-pdf, which honestly is more or less dead in terms of activity, which sucks. Web-pdf gives me the flexibility of DocBook-XSL (and then some!) but with CSS and, if I need it, JS. Unfortunately, LoT/LoF still needs Asciidoctor extensions . . but you get a lot of toys that aren't possible with asciidoctor-pdf/prawn. [3] Shared by vivliostyle and a few others.
yboris 3y ago
Cool! This was one of the tools I considered to help get the open-access textbook to its print version (to be published later in 2024). Since I was using Hugo I went with some custom CSS that gets enabled during the PDF build phase and website2pdf to handle the generation: https://github.com/jgazeau/website2pdf https://github.com/jgazeau/website2pdf Open-access textbook: https://www.utilitarianism.net/ https://www.utilitarianism.net/ Open source: https://github.com/whyboris/utilitarianism.net https://github.com/whyboris/utilitarianism.net

yawnxyz 3y ago

I’ve designed and printed many conference abstract books with PagedJS! Love that thing

strogonoff 3y ago

I wonder how the finer issues of typesetting are handled with print CSS compared to dedicated typesetting software nowadays. CSS is very compelling, but then based on my personal experience as print media designer the likes of InDesign are full of various special tricks (and language-specific, too) for alleviating white space corridors, handling hanging punctuation, hyphenation, etc. that the enterprise-level software tends to accumulate (due to the business model if nothing else).

sings 3y ago
It is limited and depends on the browser used to print the document. The most glaring missing feature is CMYK colour. I’ve just set up our publications to use PagedJS, and with a fair amount of hacking I was able to set up a baseline grid. Hyphenation depends on the browser implementation, which is OK for English in recent Chromium. The new text-wrap property has also been helpful. Hanging punctuation is only supported in Safari if I remember correctly. But being able to produce nice looking PDFs from a markdown document, with automated endnotes and table of contents, is a much nicer process than going through InDesign, and I also say this as someone equally comfortable with both. And the result is good enough for our purposes. Here is an example: https://www.lowyinstitute.org/sites/default/files/2024-03/LAVEIL-Papua-New-Guineas-fiscal-decentralisation.pdf https://www.lowyinstitute.org/sites/default/files/2024-03/LA...
- strogonoff 3y ago
  I agree that InDesign generally is clunky (the same reason it has a lot of typesetting black magic: business model where you make money by satisfying requests of perfectionist designers and their managers). However, in the past, while I was still doing relevant work, I had mild success abstracting some of it out by defining a template and populating it with data imported from JSON. Now I’m not using ID much, and struggling with generating PDFs from HTML, so I really appreciated the example you gave. Great work!
dylan604 3y ago
The lack of manual kerning to avoid rivers of white space is something that I wouldn't even begin to know how to tackle in CSS. Maybe I'm just too muscle memory familiar with the tools in DTP vs CSS for Web, that I'm just not familiar with the proper CSS for it. The wysiwyg of DTP apps is like pure training wheels or a warm fuzzy blanket in getting work done
- strogonoff 3y ago
  A large amount of   and spans with letter-spacing or font-kerning can help, but no one’s going to do that (unless you go for an extremely fixed layout or engage JavaScript, which I would consider in poor taste for these purposes). I concur on the warm fuzzy blanket of DTP software, personally.
  - dylan604 3y ago
    exactly. that sounds like a pretty good description of hell to me. i much prefer highlighting the text, alt/option-left/right to adjust the kerning in real time. this type of description of using CSS for DTP reminds me of using tables for layout before CSS. it was a bullshit solution waiting for something better. only, in this case, DTP software is already there and better. so why would someone do this to themselves?
    - strogonoff 3y ago
      I imagine to avoid paying expensive license fees, to stick with OSS out of principle, and/or to implement various fun integrations.
      - dylan604 3y ago
        oh to be young and a dreamer. now, i just want to get work done with the most efficient tool for the job. that kind of hell is for the young
        strogonoff 3y ago
delhanty 3y ago
> but then based on my personal experience as print media designer the likes of InDesign are full of various special tricks (and language-specific, too) That seems to concur with an informative article by AtaDistance from 2019 that I read the other day [0]: > ... > The result was InDesign 1.0 J which shipped in early 2001. InDesign J was the first, and only, major software application developed outside of Japan that followed the Japanese Industrial Standard (JIS) X4051 typesetting and composition specification (the kumihan “bible”) and traditional Japanese print production methods. > I have covered some basics of Japanese layout before, but a review is helpful for first time readers. I’ll use a mix of my material and McCully’s presentation to explain. > ... > Western created DTP layout is graphics-driven and calculated by margins and font baselines. The western baseline typography model and font metrics is how PostScript and OpenType fonts, and all layout engines evolved. Adobe was well acquainted with the shortcomings of their own font technology and InDesign J got around the problems by adding proprietary Kanji virtual body font metrics and Japanese line break algorithms. None of this exists as an open standard that benefits everybody. > That is fine for InDesign and print production, but web layout and typography via CSS is an entirely different world. There are 3 huge obstacles for good vertical Japanese typography on the web: > * No font metrics for virtual body/em-box glyph space placement: everything has to be accomplished with baseline metrics > * No reliable space control > * No reliable line breaks [0] https://atadistance.net/2019/04/26/the-state-of-css-japanese-layout-open-type-variable-fonts-and-why-apple-news-wont-happen-in-japan/ https://atadistance.net/2019/04/26/the-state-of-css-japanese...
- strogonoff 3y ago
  This brings me back to when I did a gig typesetting a Japanese language book (short, maybe couple dozens of pages) once. I don’t even speak Japanese all that well, the guy basically looked for someone with IDJ (which I had coincidentally) and basic skill to operate it. The software handles most of the magic. As a designer, I won’t pretend I didn’t feel a little used.

MilStdJunkie 3y ago

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[3]: the dependency on browser rendering kit. [1] https://github.com/ggrossetie/asciidoctor-web-pdf https://github.com/ggrossetie/asciidoctor-web-pdf [2] Asciidoc has four major PDF pipelines in some form of maintenance. The vanilla, asciidoctor-pdf, is a Ruby-based Prawn PDF generator, and it's good but limited in terms of layout - you end up having to extend the core Asciidoctor processor for a lot of tricks like LoT/LoF. Asciidoctor-pdf, and I really want to emphasize this, is the official PDF pipeline for adoc files. The older pipeline, FOPUB, is based on DocBook, which Asciidoc has equivalency with. But DocBook means XSL, and XSL means cheating on Russian roulette because just one out of six chance of ENDING THE PAIN is not enough. The odd man out is DBLATEX, which goes Asciidoc->DocBook->LaTeX-> PDF, and . . whew, ok man, you're jumping three markup languages, dude. Other than that, LaTeX is pretty much the gold standard for layout markup. Finally, we got this thing, asciidoctor-web-pdf, which honestly is more or less dead in terms of activity, which sucks. Web-pdf gives me the flexibility of DocBook-XSL (and then some!) but with CSS and, if I need it, JS. Unfortunately, LoT/LoF still needs Asciidoctor extensions . . but you get a lot of toys that aren't possible with asciidoctor-pdf/prawn. [3] Shared by vivliostyle and a few others.

yboris 3y ago

Cool! This was one of the tools I considered to help get the open-access textbook to its print version (to be published later in 2024). Since I was using Hugo I went with some custom CSS that gets enabled during the PDF build phase and website2pdf to handle the generation: https://github.com/jgazeau/website2pdf https://github.com/jgazeau/website2pdf Open-access textbook: https://www.utilitarianism.net/ https://www.utilitarianism.net/ Open source: https://github.com/whyboris/utilitarianism.net https://github.com/whyboris/utilitarianism.net