retypesetting.diffDescription: Text Data
|
| From: | G. Branden Robinson |
| Subject: | Re: Disposition of groff 1.23.0.rc4 feedback issues |
| Date: | Thu, 20 Apr 2023 22:31:50 -0500 |
[dropping Bruno Haible from CC, on the assumption that he's not
interested in ms(7) details]
At 2023-04-21T00:02:54+0200, Christof Meerwald wrote:
> On Thu, Apr 20, 2023 at 03:00:45PM -0500, G. Branden Robinson wrote:
> > 2. addressed in documentation on master (NEWS) prior to RC4
> > (f9e84954174); reporter remains unhappy, but does not respond to
> > requests for more precise information
>
> I guess the technical details should be well understood by now and are
> pretty obvious anyway.
Excellent--we start out with an implied insult. Only a moron would have
made the changes to ms(7) that I did. Championship rhetoric!
> A simple test case has been posted in
> https://mail.gnu.org/archive/html/groff/2023-04/msg00137.html
Your choice of the passive voice conceals the fact that _you_ composed
that message.
When you're complaining about a bug and a software developer
volunteering to work on the problem asks you for more information, it's
not simply polite but more efficacious to _respond to that request_.
https://mail.gnu.org/archive/html/groff/2023-04/msg00142.html
The fact that you neglected to reply combined with the suggestion that
any response is not worth of the time of a person intelligent enough to
apprehend the "obvious" "technical details" is a tactic I've seen
employed many times by brogrammers and (bad) managers. Typically what
it attempts to conceal is that the speaker doesn't, in fact, know what
they're talking about.
Is this how you want to be regarded by your peers? Wait--let me guess,
you are without peer. Fine, then--is this how you want to be regarded
by people who have _elected_, _voluntarily_, to field your hectoring
complaints?
If you think my patience for your attitude is infinite, you have
miscalculated. But I still have enough for the nonce to meet you on
your own ground--that of scope creep.
[relocated from the end]
> BTW, the NEWS entry doesn't mention ".TE" and also doesn't mention
> that pre-heading space is then also omitted (which is actually the
> most obvious/annoying difference). And while we are at it - what about
> ".PE"?
>
> And in documents where PD is significantly larger than DD, why would I
> only want DD spacing? If accumulation of DD+PD spacing is too big,
> maybe just using the maximum of DD and PD would be the more desirable
> option?
>
> And yes, maybe next week I'll notice more differences/regression in
> other documents... (I just haven't looked at any other documents yet)
Well, then, yes, let's play, and ramble all over the place with a
thoroughly annotated discussion of the "Typesetting Mathematics --
User's Guide (Second Edition); see below.
> together with the output from groff 1.22.4 and 1.23.0.rc4 that shows a
> significant difference in vertical spacing.
"Significant" is a subjective term. But I'll grant that it beats your
pixel measurements, which are inescapably dependent on factors like how
far you've zoomed the document view (even if scaling is linear, there
are always integer rounding issues to bedevil us). Your use of the `nl`
register in message #137 (above) however, was a good step toward
detection of and remedy of a potential defect. So good on you for that.
> In https://mail.gnu.org/archive/html/groff/2023-04/msg00097.html it
> has been pointed out
Again, the use of passive voice to suggest a chorus of dissatisfied
users when, so far, only you have complained, is deceitful rhetoric.
> how these changes affect the formatting of "Typesetting Mathematics -
> User's Guide (Second Edition)" by Kernighan and Cherry with 1.23.0.rc4
> and where 1.23.0.rc4 now shows formatting differences that weren't
> there with 1.22.4.
Well, then, let us see how groff 1.22.4 did with this document.
First I will present a diff of the two trees I used to prepare it. I
chose to create a Makefile and make some minor changes to the document's
original source for reasons that are (mostly) annotated and, to use your
term, "obvious".
Let us peruse. I trust that you (or anyone else reading this
discussion) will point out if I have made changes to the document that
are ruinously deceptive.
Two points to make:
1. The sources can be obtained from TUHS.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/eqn/
2. We're interested for the time being only in the "g" document, the
User's Guide. That is the one that appeared in the Volume 2 of the
Version 7 Unix Programmer's Manual and scans of which I consulted,
motivating my changes to groff ms.
Not that, as we've seen (and as we will again below), any attempts
to get you to control the scope of your complaints so that one can
be addressed before you raise several others ever does any good.
diff -urN eqn-v7-pure/Makefile eqn-v7-hacked/Makefile
--- eqn-v7-pure/Makefile 1969-12-31 18:00:00.000000000 -0600
+++ eqn-v7-hacked/Makefile 2022-07-12 18:32:50.395729199 -0500
@@ -0,0 +1,21 @@
+# Set this macro to where your groff executable is located. For best
+# results, ensure that it locates an s.tmac file with some fixes applied
+# (Savannah #62686, #62687, #62688).
+GROFF:=/home/branden/src/GIT/groff/build/test-groff
+GROFFOPTS:=-ww -e -ms -M . -m sbtl -P -e -P -pletter -T pdf
+
+ALL=eqnsystem.pdf eqnuser.pdf
+
+all: $(ALL)
+
+EQNSYSTEMSRCS:=e.mac e0 e1 e2 e3 e4 e5 e6 e7
+EQNUSERSRCS:=g.mac g0 g1 g2 g3 g4 g5
+
+eqnsystem.pdf: sbtl.tmac $(EQNSYSTEMSRCS)
+ $(GROFF) $(GROFFOPTS) $(EQNSYSTEMSRCS) >$@
+
+eqnuser.pdf: sbtl.tmac $(EQNUSERSRCS)
+ $(GROFF) $(GROFFOPTS) $(EQNUSERSRCS) >$@
+
+clean:
+ rm -f $(ALL)
[e0 removed from diff]
diff -urN eqn-v7-pure/g.mac eqn-v7-hacked/g.mac
--- eqn-v7-pure/g.mac 2022-06-30 16:28:19.984161912 -0500
+++ eqn-v7-hacked/g.mac 2022-07-01 11:44:16.157564585 -0500
@@ -2,6 +2,7 @@
.de SC
.NH
\\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
+.pdfbookmark 1 \\$*
..
.de UC
\&\\$3\s-2\\$1\\s+2\\$2
This is a feature addition, as PDF obviously didn't exist in the late
1970s. Larry McVoy liked this one. It turns the section headings
(specified through the above document-private macro `SC`) into PDF
bookmarks, enabling them to be placed into a navigation pane in a PDF
viewer.
diff -urN eqn-v7-pure/g0 eqn-v7-hacked/g0
--- eqn-v7-pure/g0 2022-06-30 18:38:30.234150358 -0500
+++ eqn-v7-hacked/g0 2022-07-12 18:34:32.767246144 -0500
@@ -1,9 +1,27 @@
+.\" Adapted for groff by G. Branden Robinson, 2022-06-30/07-02. Thanks
+.\" to Deri James for PDF support.
+.\" These values, used with URW Times fonts at 10 points, produce column
+.\" and page breaks nearly identical to the C/A/T typeset original.
+.nr LL 5.4i
+.nr PO 1.55i
One can of course charge the foregoing with some form of treason to
fidelity. The practical reason for these register settings is that the
PostScript fonts we use to render the document don't have identical
metrics to those used my the Graphic Systems C/A/T phototypesetter used
to set the print of the manual where this "Typesetting Mathematics"
document was (most?) widely published in the 1979-1983 time frame.
Every year or so when I endorse the goal of faithful reproduction of
historical documents, Ralph Corderoy takes a run at me to try to get me
to embrace the objective of pixel-perfect reproduction. Because the
C/A/T's fonts weren't even digitally encoded (they were on photographic
plates), and in any case due to the preponderance of digital fonts being
subject to copyright licensing[1], this objective is, in general,
impossible to meet.
Since you attempt to freight your personal whims with the weight of the
Groff Mission Statement below, I will point out that it does not make
sense to identify an impossible goal as a "top priority". (That
ideologues do so anyway does nothing to rehabilitate the principle.)
+.\" Define a fake Bell System logo.
+.char \[bs] \o'\[ci]|'
The Bell logo is trademarked. We can't just traffic in it without
permission. Well, maybe the one from the 1970s isn't. Which one is
correct to render? That depends on when the document was typeset.
We'll meet another example of this sort of problem below, with the Unix
trademark.
Next I replace some "document description information".
.EQ
delim $$
.EN
-\".ND "June 2, 1976"
-.RP
-\".TM "76-1273-4 76-1271-4" 39199 39199-11
+.
+.af year 0000
+.af mo 00
+.af dy 00
+.ND "August 15, 1978 \fI(retypeset with \fPgroff\fI\
+ \n[year]-\n(mo-\n(dy)"
+.\" GBR: Suppress repetition of doc info and don't alter page numbering.
+.RP no-repeat-info no-renumber
+.\" Force page 1 to be numbered; it follows the cover page and the Unix
+.\" Programmer's Manual page headings (which these sources don't produce
+.\" anyway) are not appropriate for this document in isolation.
+.\"nr pg*P1 1
+.\"TM "76-1273-4 76-1271-4" 39199 39199-11
groff ms does not support the `TM` macro and never has. We do not
support the cover sheet styles where technical memorandum identifiers
would be placed, and never have.
It remains to be seen whether my attempt at frankness regarding what was
doing the typesetting, and when, also offends your principle of rigid
fidelity to "the original".
.TL
Typesetting Mathematics _ User's Guide
\&\ \ \ \ \ (Second\ Edition)
@@ -12,13 +30,18 @@
.AI
.MH
.AB
-.in
-.ll
+.\" This document uses the full page width for the abstract.
+.\"in
+.\"ll
+.nr 0:li 0
+.nr 0:ri 0
You could certainly yell about this. But I wouldn't (not that you'll
listen to _me_); Lesk 1978 does not endorse the usage of `in` and `ll`
requests in ms documents.[2]
+.pdfinfo /Title Typesetting Mathematics - User's Guide (Second Edition)
+.pdfinfo /Author Brian W. Kernighan and Lorinda L. Cherry
Again, I decided to add support for PDF features, for user convenience.
.PP
This is the user's guide for a system for typesetting
mathematics,
using
-the phototypesetters on the
+the \%photo\%typesetters on the
This is the first of several similar changes. It is somewhat well known
that AT&T troff and GNU troff use different hyphenation systems. In the
absence of TeX hyphenation patterns for English that happen to exactly
reproduce those selected by AT&T's "suftab" system (developed by Molly
Wagner, I think), differences in hyphenation breaking are inevitable.
This would be a good project for you to undertake.
.UX
and
.UC GCOS
@@ -28,35 +51,42 @@
designed to be easy to use
by people who know neither mathematics nor typesetting.
Enough of the language to set in-line expressions like
-$lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1$
+.\" Correct missing space after n for GNU eqn. GBR, 2022.
+$lim from {x -> pi /2} ( tan~x) sup{sin~2x}~=~1$
There are some other fine details of how equations are set in this
document that I don't like, but I haven't chased them down yet, or even
opened a Savannah ticket for them, but I'm aware of them.
I do observe that it may be a poor use of my time to engage with you
when I could pursing that activity, which might improve the experience
of many more users.
or display equations like
-.in .5i
+.\"in .5i
Again, Lesk doesn't endorse use of `in` requests. Should this do
something? Even if the resulting indentation is the same without it?
.EQ I
G(z)~mark =~ e sup { ln ~ G(z) }
~=~ exp left (
sum from k>=1 {S sub k z sup k} over k right )
~=~ prod from k>=1 e sup {S sub k z sup k /k}
.EN
+.\" Use "cdots" for ellipses on the math axis; "ldots" on the baseline.
+.\" Redefine them to space them more widely. Use ~ more generously than
+.\" K&C; groff eqn tends to horizontally pack more tightly. Keep the
+.\" copy of this in file "g4" in sync.
The difference between AT&T eqn and GNU eqn's handling of the "..."
token has been documented since February 2007, in commit 62248e78a3 by
Eric Raymond.
.EQ I
+define cdots "{ \[md]~\[md]~\[md] }"
+define ldots "{ .~.~. }"
lineup = left ( 1 + S sub 1 z +
-{ S sub 1 sup 2 z sup 2 } over 2! + ... right )
-left ( 1+ { S sub 2 z sup 2 } over 2
+{ S sub 1 sup 2 z sup 2 } over 2! + ~ cdots right )
+~ left ( 1+ { S sub 2 z sup 2 } over 2
+ { S sub 2 sup 2 z sup 4 } over { 2 sup 2 cdot 2! }
-+ ... right ) ...
++ ~ cdots right ) ~ cdots
The foregoing is the natural consequence of the aforementioned
difference, plus some conveniences. The special character \[md] did not
exist in AT&T troff (at least not Ossanna troff). (Not even if you
spell it as "\(md".)
.EN
.EQ I
lineup = sum from m>=0 left (
sum from
-pile { k sub 1 ,k sub 2 ,..., k sub m >=0
+pile { k sub 1 ,k sub 2 , ~ ldots ~ , k sub m >=0
above
-k sub 1 +2k sub 2 + ... +mk sub m =m}
+k sub 1 +2k sub 2 + ~ cdots ~ +mk sub m =m}
{ S sub 1 sup {k sub 1} } over {1 sup k sub 1 k sub 1 ! } ~
{ S sub 2 sup {k sub 2} } over {2 sup k sub 2 k sub 2 ! } ~
-...
+cdots
{ S sub m sup {k sub m} } over {m sup k sub m k sub m ! }
-right ) z sup m
+right ) ~ z sup m
These are cdots/ldots and (horizontal) equation spacing revisions as
already discussed.
.EN
-.in 0
+.\"in 0
Since we didn't need the manual indentation request before, we won't
need to undo it.
can be learned in an hour or so.
.PP
The language interfaces directly with
@@ -73,11 +103,13 @@
.UC UNIX
formatter
.UC NROFF
-to set mathematical expressions on
+to set mathematical \%expressions on
The hyphenation issue again.
.UC DASI
and
.UC GSI
terminals
and Model 37 teletypes.
+.\" TODO: Force the first body page to be numbered "2" to align with PDF
+.\" page numbers.
.AE
-.CS 11 0 11 0 0 3
+.\"CS 11 0 11 0 0 3
groff ms does not support the Labs-specific `CS` macro. I trust you can
locate the discussion of this in the ms document to which you linked.
diff -urN eqn-v7-pure/g1 eqn-v7-hacked/g1
--- eqn-v7-pure/g1 2022-06-30 16:28:19.984161912 -0500
+++ eqn-v7-hacked/g1 2022-07-01 20:39:52.463882265 -0500
@@ -1,3 +1,6 @@
+.\" Force extra-large blank area at top of page to match original.
+.sp 10v
Be sure and let me know if I mismeasured that.
+.nr MINGW 5.875n
This is present for the same reason as my adjustments to the line length
and page offset; it accommodated the non-original fonts in use and
caused the page, column, and even line breaks to occur where they did in
the AT&T troff rendering in nearly every case.
.if t .2C
.SC Introduction
.PP
@@ -400,6 +403,7 @@
e sup {i omega t}
.P2
is
+.\" This equation got lost in the V7 Volume 2 manual!
.EQ
e sup {i omega t}
.EN
This is the item you repeatedly refuse to engage with in any way.
Absolute fidelity to AT&T troff/ms rendering will require that I
contrive a means of disposing of this equation. Furthermore, and as I
have already pointed out to you, its absence could be explained by an
vertical space management error in the original implementation. An
off-by-one or similar mistake could have caused this one-line equation
to go missing from the bottom of its column, when the assumption of the
code was that it didn't, and that in turn would be why the next column
on the page has apparently spurious vertical space at its _top_, meaning
that the column tops are not in alignment, as one normally desires.
Should backward compatibility with bugs be a "top priority"?
I have confidence in you to express your view on that question in a
manner that comports adequately with your supercilious attitude.
@@ -523,6 +527,7 @@
.EQ
sqrt a+b + 1 over sqrt {ax sup 2 +bx+c}
.EN
+.KS
Warning _ square roots of tall quantities look lousy,
because a root-sign
big enough to cover the quantity is
@@ -534,6 +539,7 @@
.EQ
sqrt{a sup 2 over b sub 2}
.EN
+.KE
Possibly I could have solved this problem like a Real Programmer,
shoving `sp` requests in and fiddling them until a satisfactory layout
was achieved; but it seemed simpler to--hold on here--use the facilities
of the macro package.
Big square roots are generally better written as something
to the power \(12:
.EQ
@@ -603,6 +609,7 @@
lim from {n \(mi> inf} x sub n =0
.P2
is
+.\" Correct missing space after n for GNU eqn. GBR, 2022.
.EQ
-lim from {n-> inf} x sub n =0
+lim from {n -> inf} x sub n =0
The foregoing arises from a difference in the way the AT&T and GNU eqn
implementations lexically analyze their input streams.
I don't think the very paper we're talking about admits the foregoing
construction, but obviously AT&T eqn accepted it. Should this be
another "top priority" backwards compatibility item, or should we spill
electrons on more important matters?
.EN
diff -urN eqn-v7-pure/g2 eqn-v7-hacked/g2
--- eqn-v7-pure/g2 2022-06-30 16:28:19.984161912 -0500
+++ eqn-v7-hacked/g2 2022-06-30 22:42:34.436500637 -0500
@@ -181,9 +181,11 @@
is not subject to any of the font changes and spacing
adjustments normally done by the equation setter.
This provides a way to do your own spacing and adjusting if needed:
+.KS
.P1
italic "sin(x)" + sin (x)
.P2
+.KE
Another venial sin, using the facilities Lesk provided instead of
fiddling with `ne` and `sp` requests.
is
.EQ
italic "sin(x)" + sin (x)
@@ -281,6 +283,7 @@
if at all possible.
Thus, for example,
you can say
+.KS
.P1
^EQ I
x+y mark = z
@@ -296,6 +299,7 @@
.EQ I
x lineup = 1
.EN
+.KE
Keeps again.
For reasons too complicated to talk about,
when you use
.UC EQN
@@ -428,11 +432,18 @@
right ]
.P2
will make
+.\" Cheat #1: AT&T eqn stacked piles more tightly than GNU eqn.
.EQ
+set baseline_sep 1v
A ~=~ left [
pile { a above b above c } ~~ pile { x above y above z }
right ]
.EN
+.\" Reset equation baseline separation to the default, which is not
+.\" documented anywhere and has no syntactical access. :-/
+.EQ
+set baseline_sep 140
+.EN
The elements of the pile (there can be as many as you want)
are centered one above another, at the right height for
most purposes.
An explicitly documented, vertical space-relevant cheat!
The next two changes go together.
@@ -466,6 +477,9 @@
.ul
cpiles
than it is for ordinary piles.
+.\" Cheat #2: Shrink the display distance a bit to fit this display on
+.\" the page.
+.nr DD -0.25v
.P1 2
roman sign (x)~=~
left {
@@ -473,6 +487,7 @@
~~ lpile
{if~x>0 above if~x=0 above if~x<0}
.P2
+.nr DD +0.25v
makes
.EQ
roman sign (x)~=~
This is how people _should_ do this sort of thing. Not with `.sp
-0.25v` or some nonsense like that.
diff -urN eqn-v7-pure/g4 eqn-v7-hacked/g4
--- eqn-v7-pure/g4 2022-06-30 16:28:19.984161912 -0500
+++ eqn-v7-hacked/g4 2022-07-01 20:51:50.768616704 -0500
@@ -2,10 +2,10 @@
.PP
Here is the complete source for the three display equations
in the abstract of this guide.
-.sp
-.nf
+.DS L
My God, I yet again used the facilities of the macro package. Also,
I'll note for those keeping score that while Lesk does admit use of
`sp` in ms document, he doesn't extend that courtesy to `nf`. (Nor
`fi`).
.ps -2
.vs -2
+.\" Keep the copy of this in file "g0" in sync.
.EQ I
G(z)~mark =~ e sup { ln ~ G(z) }
~=~ exp left (
@@ -13,26 +13,27 @@
~=~ prod from k>=1 e sup {S sub k z sup k /k}
.EN
.EQ I
+ define cdots "{ \[md]~\[md]~\[md] }"
+ define ldots "{ .~.~. }"
lineup = left ( 1 + S sub 1 z +
- { S sub 1 sup 2 z sup 2 } over 2! + ... right )
- left ( 1+ { S sub 2 z sup 2 } over 2
+ { S sub 1 sup 2 z sup 2 } over 2! + ~ cdots right )
+ ~ left ( 1+ { S sub 2 z sup 2 } over 2
+ { S sub 2 sup 2 z sup 4 } over { 2 sup 2 cdot 2! }
- + ... right ) ...
+ + ~ cdots right ) ~ cdots
.EN
.EQ I
lineup = sum from m>=0 left (
sum from
- pile { k sub 1 ,k sub 2 ,..., k sub m >=0
+ pile { k sub 1 ,k sub 2 , ~ ldots ~ , k sub m >=0
above
- k sub 1 +2k sub 2 + ... +mk sub m =m}
+ k sub 1 +2k sub 2 + ~ cdots ~ +mk sub m =m}
{ S sub 1 sup {k sub 1} } over {1 sup k sub 1 k sub 1 ! } ~
{ S sub 2 sup {k sub 2} } over {2 sup k sub 2 k sub 2 ! } ~
- ...
+ cdots
{ S sub m sup {k sub m} } over {m sup k sub m k sub m ! }
- right ) z sup m
+ right ) ~ z sup m
I have already addressed these changes.
.EN
-.sp
-.fi
+.DE
...as I have these.
.ps +2
.vs +2
.SC "Keywords, Precedences, Etc."
@@ -61,7 +62,7 @@
Digits, parentheses, brackets, punctuation marks, and these mathematical words
are converted
to Roman font when encountered:
-.P1
+.P1 3 \" reduce indentation, GBR 2022
sin cos tan sinh cosh tanh arc
max min lim log ln exp
Re Im and if for det
@@ -140,7 +141,7 @@
.sp
.nf
.in .2i
-.ta .7i 1.4i 2.1i
+.ta .7i 1.4i 2.0i \" reduce last tab stop, GBR 2022
above 17, 18 lpile 17
back 21 mark 15
bar 13 matrix 18
This is another case where I think font metrics make a difference.
Possibly the glyphs in Adobe Times Roman were on average a little fatter
than those provided by Graphic Systems.
Finally, I added a new file to the proceedings.
diff -urN eqn-v7-pure/sbtl.tmac eqn-v7-hacked/sbtl.tmac
--- eqn-v7-pure/sbtl.tmac 1969-12-31 18:00:00.000000000 -0600
+++ eqn-v7-hacked/sbtl.tmac 2022-07-12 17:47:22.380362899 -0500
@@ -0,0 +1,16 @@
+.rm MH
+.de MH
+Bell Laboratories
+Murray Hill, New Jersey 07974
+..
+.de UX
+.nr btl*seen-UX-macro 0
+.ds btl*UX-suffix \(dg\"
+\s[\\n[.s]*8u/10u]UNIX\s0\\$1\\*[btl*UX-suffix]
+.if !\\n[btl*seen-UX-macro] \{\
+. FS \\*[btl*UX-suffix]
+. nop UNIX is a Trademark of Bell Laboratories.\" sic
+. FE
+. nr btl*seen-UX-macro 1
+.\}
+..
The foregoing exists for the reason documented in ms.ms, with which you
claim to be familiar. (Do I overstep by assuming you've _read_ it, as
opposed to finding vertical space to complain about?)
> As a bonus I should maybe also mention that even the ms.ms document is
> (in my view, negatively)
An admission of subjectivity! Keep that up--it's a good look on you.
> affected by these changes (and not just
> because of the .bp request) - compare the vertical space before "5.3
> Paragraphs" with the vertical space before "5.8 Keeps, boxed keeps,
> and displays".
Yes. I did say previously that post-display vertical spacing should
probably _not_ accumulate with pre-heading spacing, and that moreover we
might want to introduce a new register admitting user tunability of
pre-heading spacing. This is a worthy point--but it is worth holding up
the groff 1.23.0 release for?
> There is also surprisingly little vertical space before
> "8.2. Berkeley ms accent mark and glyph strings" (when there is a lot
> more vertical space before "8.1. AT&T ms accent mark strings"). That's
> all visible in
> https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?preview=ms.2023-04-17.pdf
Those are additional instances of the same issue: `TE` before `NH`.
> This should all be seen in the context of the Groff Mission Statement:
>
> "Backward compatibility with existing documents and usage will
> remain a top priority, as will avoiding feature-bloat and increased
> overheads."
>
> When there are these formatting differences even in its own
> documentation, there really isn't much value in a promise of "backward
> compatibility".
We fix formatting and other problems in our documentation _all the
time_. Try reading some of the past 4,500 commits to the groff Git
repository to get an idea of how much of this activity takes place.
Both groff 1.22.4 and groff Git render the equation from the K&C paper
(above) that AT&T troff didn't in 1979. I appreciate that you interpret
the Groff Mission Statement as mandating that we keep groff frozen and
unmaintained, but to hold to that principle you will have to decide
whether it should change to better reproduce AT&T bugs, or to better
reproduce its own historical bad behavior.
I surmise that you sense the tension in these goals, which is why you
keep refusing to engage my point about the missing equation as AT&T
rendered the K&C paper.
> commits responsible for all these changes:
> 3061f20f53e3616a8577fd2ecce1b068d0d66dd4 and
> 783f3c2745b8132a9b7fa99bd1b241d2e34f4398
>
> BTW, the NEWS entry doesn't mention ".TE" and also doesn't mention
> that pre-heading space is then also omitted (which is actually the
> most obvious/annoying difference).
I asked you--or an anonymous Savannah user whose concerns uncannily
coincide with yours in both topic and timing--directly whether you
thought documenting this would be an adequate remedy for the release[3]
(since Bertrand, our maintainer, desired only documentation changes for
1.23.0.rc4), and you, as usual, did not answer.
> And while we are at it - what about ".PE"?
Another fabulous example of Christof Meerwald scope control.
At any rate, I see no reason not to handle pic(1) inclusions like other
displays. So what I envision is applying DD display distance to them
(before and after), not permitting that space to accumulate with
pargraph distance (PD), _but_ allowing it to accumulate with pre-heading
distance (for which we have no register as yet--and AT&T ms obviously
did not [not one that was documented, anyway]).
> And in documents where PD is significantly larger than DD, why would I
> only want DD spacing? If accumulation of DD+PD spacing is too big,
> maybe just using the maximum of DD and PD would be the more desirable
> option?
These are good questions. One wonders why Lesk 1978 (the document) or
Version 7 Unix ms doesn't address these questions with perfect clarity.
Oh, I think I know your answer--whatever it did is perfect. We'll treat
it as a TRIP test even though it was neither designed that way nor
intended to serve as an immutable model.[4] (We know that from 4.2BSD's
ms as well as Research Unix's.)
...which leads us right back to the missing equation problem...again.
> And yes, maybe next week I'll notice more differences/regression in
> other documents... (I just haven't looked at any other documents yet)
You might need to find another groff developer to advocate for your
issues. At this point I find my supply of patience with you is spent.
So that other people can help, I'm also attaching PDFs of the K&C
document as rendered by groff 1.22.4 and 1.23.0. I made a couple of
other small changes to the source document (involving the `RP` macro
call and defining `CF` to get a page footer identifying the renderer).
I'm also attaching a scan of the document as rendered (presumably) by V7
Unix troff. The page headers and footers were replaced by the publisher
Holt, Reinhart, and Winston. I hope that these resources will permit an
informed discussion of which aspects of backward compatibility, a "top
priority" (with which version of which formatter?) to retain at the
expense of others.
To avoid getting lost in a mountain of details, I would pose some simple
tests that the reader can evaluate, recognizing that errors in vertical
space amounts tend to accumulate: what text is on the last page of
"Typesetting Mathematics" in the trade press version? What text is on
groff 1.23.0's rendering of the document? How do those compare? What
text does groff 1.22.4 put on the last page? How well does _that_
compare to the trade press version? (You may, if you wish, repeat this
procedure for page 10, page 9, ...)
On net, is groff 1.23.0(.rc4)'s rendering of the document a regression
from that of groff 1.22.4, or not?
That is the essential question we must ask ourselves in a thread
entitled "Disposition of groff 1.23.0.rc4 feedback issues".
I think Christof Meerwald will gate our release forever if we let him.
That is why he keeps pivoting from one purported defect to another, and
promises to find more next week.
I say, don't let him gate our release forever.
Optimistically, if every groff release cycle has a Michael F. Witten,
that we've found ours for 1.23.0 reassures me that soon we really will
be able to get this thing out the door.
Irascibly,
Branden
[1] Simple bitmap fonts excepted in some jurisdictions (like the U.S.)
but not, as I understand it, in others (like Japan).
[2] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/msmacros/ms
[3] https://savannah.gnu.org/bugs/index.php?64043#comment6
[4] I think I am beginning to understand at last the bifurcation between
ms and mm, which occurred far earlier (ca. 1976) than my imagination
could justify. People doing Unix typesetter support must have faced
a never-ending stream of demands from users who had wildly divergent
mental models of how the macro package should work. These users
therefore needed a macro package with a more detailed and explicit
specification, a lot more configuration knobs (because they "need
the icon in cornflower blue"), and convenience macros for formatting
itemized lists in 7 different ways instead of trusting the user to
write their own. I checked, and ms was indeed absent from Unix
System III (1980). You had mv(7) for slides (and "viewgraphs") and
mm for everything else. The Unix Room/CSRC/Room 1127 environment
must have been very different from Unix Support. It was a research
lab. One was expected to figure things out for oneself, and exhibit
a bit of deference[5] to those with more longevity who had
implemented the thing you were trying to use, and worked just down
the hall. (And even if you didn't want to "defer" to them, you
could _go ask them_ why a thing was the way it was.) Thanks to
Damian McGuckin for gently steering me in the direction of this
insight without expressing it in the gauche manner that I have.
[5] Albeit, perhaps, sometimes too much--but I'll practice my Thompson
iconoclasm on another occasion. I have no fear that one will arise.
retypesetting.diff
Description: Text Data
typesetting-mathematics-HRW.pdf
Description: typesetting-mathematics-HRW.pdf
eqnuser-1.22.4.pdf
Description: Adobe PDF document
eqnuser-1.23.0.rc4.pdf
Description: Adobe PDF document
signature.asc
Description: PGP signature
| [Prev in Thread] | Current Thread | [Next in Thread] |