[bug #64043] regression introduced with bug #62688: [ms] inter-display distance accumulates with other vertical space--it should not

[G. Branden Robinson]

Update of bug #64043 (project groff):

                  Status:                    None => Rejected               
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:


> the changes made under bug #62688 actually do the exact opposite of what is
claimed in that bug

No, they don't.  The summary of the bug is "inter-display distance accumulates
with other vertical space--it should not".

And the resolution performs exactly what one would expect from the summary;
vertical space between displays is no longer cumulative.

The is discussion about this on the mailing list remains open with several
unresolved questions, including about which formatter requests are "safe" for
use in ms documents, and what users can expect when resorting to them.

Quoting the cited email message, since the submitter could not be bothered to
making a concrete, measurable claim in this bug report:


Hmm, just been trying to look a bit into this.

What I found was
https://mail.gnu.org/archive/html/groff/2022-07/msg00000.html
https://mail.gnu.org/archive/html/groff/2022-07/msg00002.html and
http://www.bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_Vol_2_1983.pdf

Looking at page 158, in "8. Braces for Grouping", I see quite a bit of
white-space before

  "Rule: Braces can always be used to force EQN to treat something as
   a unit,"

which seems to correspond to 

.EQ
e sup {i omega t}
.EN
.sp
Rule:  Braces can
.ul
always
be used to force 
.UC EQN
to treat something as a unit,

in the source code. So the ".sp" clearly does affect spacing here
(after .EN).


"Quite a bit of white-space" (vertical space is meant) does not tell me
exactly how much vertical space is present or how much should be expected.  To
my eye, the amount of vertical space seems comparable; see attachments.

On the same page of the same document, AT&T troff appears to have  lost an
entire equation from the source.


   432  Braces can occur within braces if necessary:
   433  .P1
   434  e sup {i pi sup {rho +1}}
   435  .P2
   436  is
   437  .EQ
   438  e sup {i pi sup {rho +1}}
   439  .EN
   440  The general rule is that anywhere you could use some single
   441  thing like


> the changes result in less faithful rendering of historic documents.

In authentically rendered Version 7 Unix typesetter output, the equation at
lines 437 to 439 is absent, and the top of the next column not correctly
aligned (see bug #62686).  (I suspect these are related problems.)

Again, see the attached screenshot.

I decline to resurrect this authentic misbehavior.

> Other examples of documents that are negatively affected by that change can
be found in https://github.com/n-t-roff/Plan9_troff/tree/master/sys/doc

Nope.  Vaguely waving one's hands in the direction of a huge corpus of
documents, and saying that they are somehow "negatively affected" with _no_
specifics, _no_ analysis, and _no_ historical perspective is not how
collaborative software development is undertaken.  It is simply hostile.

Closing as rejected.

(file #54619, file #54620)

    _______________________________________________________

Additional Item Attachment:

File name: savannah_64043-1.png           Size:298 KB
    <https://file.savannah.gnu.org/file/savannah_64043-1.png?file_id=54619>

File name: savannah_64043-2.png           Size:137 KB
    <https://file.savannah.gnu.org/file/savannah_64043-2.png?file_id=54620>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64043>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/