|
From: | G. Branden Robinson |
Subject: | Typesetting Mathematics by Kernighan and Cherry, retypeset in PDF |
Date: | Fri, 1 Jul 2022 21:37:16 -0500 |
Thanks to some feedback in private email from Deri James, I'm pleased to make available a PDF version of the re-typeset "Typesetting Mathematics - User's Guide (Second Edition)" by Kernighan and Cherry. Some upsides of PDF over PostScript are that: 1. The text is searchable. 2. The text is navigable. All this required was the addition of one macro call to the existing private `SC` macro defined by the document. Et voilá--all the section headings are hyperlinked in a navigation pane (if your PDF reader offers one). 3. The text has metadata for the title and authors. This was a matter of another two macro calls. I had also made an error when preparing the previous document; while trying to tidy things up for submission to this list, I accidentally regressed my patches to groff's s.tmac file in my working groff checkout. This didn't have a dramatic impact; it did cause some of the column/page breaks to not be in the same places in the scanned and re-typeset versions of this document--this was a point of parity I was eager to preserve, and I think I achieved that, modulo the missing equation in the AT&T document. Another thing I noticed is that GNU eqn tends to space glyphs more closely than AT&T eqn apparently did. This made the fancy example in the abstract downright crowded to the right of large right parentheses. Also, baseline dots and center dots were similarly crowded and, in a point of incompatibility explicitly acknowledged by the groff eqn(1) man page, we have separate eqn macros for centered and baseline dots (cdots and ldots, respectively). I added some spaces to these equations and redefined the macros within the document. An arguable advantage of this is that the document now demonstrates how and why one might redefine an eqn macro in section 22 ("A Large Example"). I did identify one further wrinkle with groff ms(7). There is too much vertical space after document titles, affecting all ms documents. This has bothered me for a long time but now that I've spent a lot more time starting at authentic V7 troff and ms output, I'm confident that it's wrong. The root cause appears to be pretty technical.[1] I don't yet have a fix for it, but it doesn't damage this document because the cover page isn't full anyway. I therefore have a fresh set of attachments. > A. The re-typeset document in PostScript format. (Until we give ms(7) > support for pdfmark, I don't see much point in rendering to PDF.) > https://savannah.gnu.org/bugs/?58946 I now have a PDF attachment, and we have more pdfmark support in ms(7) than I thought. Adding `pdfinfo` macro calls to `TL` and `AU` macros seems like it might be a good idea. Ambitious users who fill the corresponding diversions with fancy markup won't see that content reflected in PDF metadata of course, but thanks to my kludge a while back, they won't see "cannot output node in transparent throughput" noise, either, which probably deserves a medal for the most inscrutable groff diagnostic message ever.[3] > B. A diff to groff's s.tmac file, fixing issues 1, 2, and 3 above. This is unchanged; please find it in the previous mail in the thread. > C. A diff between the sources as and my hacked-up version. This > includes a Makefile for convenience and a new file, "sbtl", > implementing the only 2 AT&T Unix V7 ms macros it requires that > groff doesn't implement, or implements differently (MH and UX). I'm attaching an updated diff. > D. A compressed tar(1) archive of this hacked-up version's sources. > You will need to alter the `GROFF` macro defined in the Makefile. > If you patch s.tmac in your groff installation, defining the macro > as simply "groff" should work fine. I'm attaching an updated archive. > Feedback is appreciated. This remains the case. :) Regards, Branden [1] The `DEVTAG-EO-TL` call in our definition of ms's `TL` macro puts vertical space on the page. (If you take the call out, our post-title spacing closely matches AT&T Unix V7 ms's.) Further, this isn't ordinary vertical space, but a vertical _motion_. (One way you can tell is by inspecting the output of "groff -a", which normally does not depict vertical spacing.) I _think_ this was an unintended regression introduced many years ago when "tag" support was added into groff for the sake of grohtml and a potential generalization thereof. I spent some time poking around in src/roff/troff/node.cpp trying to understand the `tag_node` type, and reviewing Gaius and Werner's paper on the development of grohtml,[2] but I haven't yet reached any conclusions. It appears to me that motion commands are being produced in device-independent output for device tags when they shouldn't be. (One open question I have is whether motion commands should _ever_ accompany the output of device tags...shouldn't they just be placed when the appropriate drawing position is current?) [2] http://floppsie.comp.glam.ac.uk/Papers/grohtml-journal/grohtml.xhtml [3] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=557bc0558dfdee7e3f2011433cf4606052e4e7e1
eqnuser.pdf
Description: Adobe PDF document
hacking-typesetting-mathematics-2e-rev2.diff
Description: hacking-typesetting-mathematics-r2.diff
eqn-v7-hacked.tar.gz
Description: application/gzip
signature.asc
Description: PGP signature
[Prev in Thread] | Current Thread | [Next in Thread] |