Live data from Hacker News

I built a Git-tracked book production pipeline

djspeckhals.com

31–40 of 95 posts

Re: I built a Git-tracked book production pipeline

#31

Hopefully some of the writers are reading this: I love buying and reading physical books. However, about half of the books (I read mostly programming books) have letters that are printed pixelated. This is infuriating to me. No one bothers to run a trial print and see what comes out? The root cause of this: PDF will look fine, but the text color is usually set slightly off black (why!!??). The eye couldn’t really see…

> but the text color is usually set slightly off black (why!!??)

This can be cause by colour management. If the black is defined in terms of RGB and then converted to CMYK as part of the pre-press workflow, you'll typically have a mix of all four inks, and not necessarily 100% K - it depends on the colour profiles. For a black-only print job the C, M and Y channels will then be discarded, leaving a maybe-not-pure black.

Re: I built a Git-tracked book production pipeline

#32
post #10

Hopefully some of the writers are reading this: I love buying and reading physical books. However, about half of the books (I read mostly programming books) have letters that are printed pixelated. This is infuriating to me. No one bothers to run a trial print and see what comes out? The root cause of this: PDF will look fine, but the text color is usually set slightly off black (why!!??). The eye couldn’t really see…

> why is the text color set slightly off black Because pure black causes eye strain. Dark gray on white is superior for long reading sessions when your paper is white. The contrast really hurts after a while if you do pure black on pure white. This is a known phenomenon. In fact, there's experimental evidence ( https://www.nature.com/articles/s41598-018-28904-x ) that this high contrast plays a hand in the onset of m…

So the solution is to have blurry text?

Most paper in Books isn’t pure white. Leave the text completely black.

Re: I built a Git-tracked book production pipeline

#33
post #16

Earlier quoted context omitted.

> Overall, as a technical writeup I enjoyed the article; however, I would caution that the author seems to approach publishing from an amateur perspective. I also worked at a publishing company (for ~6 years) in the early 2000s. While you are right that the pros have some tricks to make the process easier, the fact remains that the process is not easy at all. Unlike in academic publishing, where nothing stands betwee…

> Once you know what all the people in a top publishing company do, the difference between an amateur publication and a professional one becomes immediately apparent. Any advise for developing this sense? I will never work in a top publishing company but I have been able to approximate good design by first studying the fundamentals, then reproducing the layouts I see in popular media. I can make text into a beautiful…

There's no substitute for apprenticeship (by whatever name). Unfortunately, skills of this kind may be close to extinction. For someone like you just interested in getting better at layout design, I'd recommend something like 'The Elements of Typographic Style', by Bringhurst; this concentrates mostly on books, but much applies to other layouts. Of more general interest -- i.e., beyond layout design -- might be 'An Encyclopedia of the Book', by Glaister. There's a wealth of valuable design and print resources from the '60s - '90s if you can find them -- some libraries still have high-quality examples, but most have replaced them with much less-valuable contemporary resources. Look for book and magazine sales by university departments, businesses, etc.

Re: I built a Git-tracked book production pipeline

#34

As someone who worked for years in commercial print, before most manufacturing moved overseas, I recall the workflows the article discusses as being more automate-able than the author seems to understand. For example, "Making the slightest change became a chore. [1.] Update the 'master' DOCX. [2.] Update the InDesign file ..." --the appropriate way to use an external document as master in InDesign is to use the Place…

> For example, "Making the slightest change became a chore. [1.] Update the 'master' DOCX. [2.] Update the InDesign file ..." --the appropriate way to use an external document as master in InDesign is to use the Place command, which autoupdates text changes as they are made in Word.

It does not auto-update. Even if it did, you wouldn't necessarily want it to auto-update, because it's very hard to tell if changing one sentence in your manuscript has borked the layout of dozens of pages. Once you have rules set up around widow and orphan control, it's very easy for even tiny text changes to have large downstream layout effects.

Also, frankly, InDesign is kind of flaky and will sometimes change layout or make other visual changes in response to apparently nothing at all. I ran into a bug where it would just silently drop underlines on some elements and jiggling them a bit would bring them back.

For my two books, I ended up writing a script that would generate a visual diff of the entire book from the PDF export of the InDesign files so that I could tell for certain if InDesign had gotten itself confused. InDesign can produce beautiful output, but like a lot of Adobe software, it's temperamental and opaque.

Re: I built a Git-tracked book production pipeline

#35
post #10

Hopefully some of the writers are reading this: I love buying and reading physical books. However, about half of the books (I read mostly programming books) have letters that are printed pixelated. This is infuriating to me. No one bothers to run a trial print and see what comes out? The root cause of this: PDF will look fine, but the text color is usually set slightly off black (why!!??). The eye couldn’t really see…

> why is the text color set slightly off black Because pure black causes eye strain. Dark gray on white is superior for long reading sessions when your paper is white. The contrast really hurts after a while if you do pure black on pure white. This is a known phenomenon. In fact, there's experimental evidence ( https://www.nature.com/articles/s41598-018-28904-x ) that this high contrast plays a hand in the onset of m…

> Dark gray on white is superior for long reading sessions when your paper is white.

Color is the ink's job. Approximating a lighter shade of black than the ink produces by speckling the output with tiny white pixels is definitely not an improvement in readability.

Re: I built a Git-tracked book production pipeline

#36
post #16

Earlier quoted context omitted.

> Overall, as a technical writeup I enjoyed the article; however, I would caution that the author seems to approach publishing from an amateur perspective. I also worked at a publishing company (for ~6 years) in the early 2000s. While you are right that the pros have some tricks to make the process easier, the fact remains that the process is not easy at all. Unlike in academic publishing, where nothing stands betwee…

> Once you know what all the people in a top publishing company do, the difference between an amateur publication and a professional one becomes immediately apparent. Any advise for developing this sense? I will never work in a top publishing company but I have been able to approximate good design by first studying the fundamentals, then reproducing the layouts I see in popular media. I can make text into a beautiful…

The trouble with our age is that, despite the abundance of intermediate-level information, expert teachers in specific, and shrinking, professions are as hard as ever to access, if not more so.

Re: I built a Git-tracked book production pipeline

#37
post #11
post #6

AKA what CS PhD students have been doing ~forever. I guess this is like medical researchers "discovering" basic calculus or an office worker discovering that SFTP, sshfs, and git work fine and they don't need Dropbox after all. What's common knowledge in one field can apparently still be alien to people outside the field, even in the age of LLMs. Just wait until the author finds out about Overleaf...

> what CS PhD students have been doing ~forever. Or what every researcher has been doing for literally decades (except with other versioning systems, but still typesetting without Word or Adobe). No need for techbros to pat themselves on the back as innovators. I typeset my novels in LaTeX and use GIT. I even just clone a base repo whenever I'm going to release another.

Considering LaTeX came from legendary CS PhD and Turing award winner Leslie Lamport's need to typeset a book, and was built on the shoulders of legendary CS PhD and Turing award winner Donald Knuth's work on TeX, I think "techbros" can safely pat themselves on the back as innovators in this case.

Re: I built a Git-tracked book production pipeline

#38
I've been making ebooks for a nonprofit using typst and pandoc for a few years and it works quite well.

We generate a pdf ebook, a print version, and a epub. They each have little tweeks but are all defined conditionally using sys.input.

It was rough at first and I've had to open around a dozen or so issues for pandoc to improve things. Now it's pretty seamless.

Re: I built a Git-tracked book production pipeline

#39

Earlier quoted context omitted.

> Once you know what all the people in a top publishing company do, the difference between an amateur publication and a professional one becomes immediately apparent. Any advise for developing this sense? I will never work in a top publishing company but I have been able to approximate good design by first studying the fundamentals, then reproducing the layouts I see in popular media. I can make text into a beautiful…

There's no substitute for apprenticeship (by whatever name). Unfortunately, skills of this kind may be close to extinction. For someone like you just interested in getting better at layout design, I'd recommend something like 'The Elements of Typographic Style', by Bringhurst; this concentrates mostly on books, but much applies to other layouts. Of more general interest -- i.e., beyond layout design -- might be 'An E…

Thank you! I have been absorbing Bringhurst methodically the past year.

I had not heard of Glaister, will be on the lookout.

Good point about library and corporate sales. My main supply of materials from the 60s has been from estate sales -- not for instructional materials, but for well composed period pieces. Older letterfaces and color palettes are so evocative; seeing the label of a 70 year old oil can with so much more personality than the products of today makes me want to bottle this style for my own future use. And it feels good to hold something back from the landfill.

Re: I built a Git-tracked book production pipeline

#40
post #6

AKA what CS PhD students have been doing ~forever. I guess this is like medical researchers "discovering" basic calculus or an office worker discovering that SFTP, sshfs, and git work fine and they don't need Dropbox after all. What's common knowledge in one field can apparently still be alien to people outside the field, even in the age of LLMs. Just wait until the author finds out about Overleaf...

I hope the negative reactions here are to the truncated title (HN drops the “How” from titles). The author doesn’t seem to be claiming anything revolutionary, just describing how they created their pipeline.

Good grief.

> Please don't fulminate. Please don't sneer, including at the rest of the community.

Post reply on HN