bug-groff
[Top][All Lists]
Advanced

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

[bug #64043] mixing formatting requests with macro calls produces differ


From: G. Branden Robinson
Subject: [bug #64043] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT&T troff
Date: Thu, 13 Apr 2023 20:04:27 -0400 (EDT)

Follow-up Comment #5, bug #64043 (project groff):

Assuming for the sake of argument that the same "anonymous" is replying as
filed the initial report...

[comment #2 comment #2:]
> In your screenshots I see 13 pixels vs. 26 pixels of vertical space 
>  before "Rule: Braces can always be..." - this seems significant to me (and
I thought that difference was obvious enough).

The magnifications of the two windows is slightly different, and may not be a
reliable guide.  troff output (before post-processing) would be more
informative.

But that is still somewhat beside the point.

There is no specification of whether interdisplay distance should accumulate
with other sources of vertical space, and my recollection is making the change
improved the document's rendering in other respects.  (Otherwise, I wouldn't
have bothered.)
  
> I fail to see the relevance of "the equation at lines 437 to 439 is absent,
and the top of the next column not correctly aligned (see bug #62686)" in the
context of this bug report.

Then let's return to...

[comment #0 original submission:]
> 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

This remark ruled in three unrelated documents; I think content on the same
column of the same page of the same document is well within scope.

But I think the objective here is to keep shifting the goal posts until I
revert the change, and you will cast about for rationales until you can find
one.

This is the only explanation I can imagine for your utter indifference to the
complete loss of text in the original document when formatted by AT&T Version
7 Unix troff.

Rewrite your document to resort to formatter requests as little as possible,
and only where the macro package exposes no locus of control for the
typesetting feature in question.  This is how macro packages have always
worked, and it is a lesson that *roff users have imparted to each other with
increasing emphasis over the years.

Allman's _me_ documentation rules in a limited set of formatter requests that
"can be used with impunity" (importantly, even then only _after_ an _me_ macro
call to initialize the package) and the DWB 3.3 _mm_ manual says that "one
seldom needs to use these requests directly".  groff man(7), mdoc(7), and
mandoc(1) discourage the use of requests at all (the last, strongly).  Peter
Schaffter's mom(7) package interposes its comprehensive interface between the
formatter and the document.

People learned the hard way that they get into unportable trouble when mixing
formatter requests with calls to the macros of full-service packages.

If you want to format Plan 9 documents _precisely_ as Plan 9 does, I suggest
using Plan 9's troff.

In the meantime, you may wish to respond to the people who offered feedback on
the groff ms(7) changes at the time, to point out how poor their vision or
judgment was.

https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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