[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Typesetting Mathematics by Kernighan and Cherry, retypeset in PDF

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.)

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.  :)


[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?)

Attachment: eqnuser.pdf
Description: Adobe PDF document

Attachment: hacking-typesetting-mathematics-2e-rev2.diff
Description: hacking-typesetting-mathematics-r2.diff

Attachment: eqn-v7-hacked.tar.gz
Description: application/gzip

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]