Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

At 2024-01-24T02:26:44+0000, Bjarni Ingi Gislason wrote:
>   This is a regression (not backward compatible)

It's a _change_.  That's why it's documented in the ChangeLog file.

It is a change that can have a significant measurable effect on user
documents.  That's why it's documented in the NEWS file.

> caused by Branden acting as a developer (not as a maintainer).

If you want something "maintained" at a point of stagnation, the easy
and obvious thing to do is to pick a version of groff that you're
satisfied with and never upgrade it.

>   This is the second case of this kind of a bug (bug #65077),

I figured some people would notice; that is why it is documented in the
NEWS file.

>  see for example "CSTR #54", chapter 5, about the 'ns' request or
> the "groff.info" (info groff) and groff(7) (incomplete).

More relevant to this topic is Lesk's paper on the ms macro package,
"Typing Documents on the UNIX System".[1]  It falls unfortunately short
of a strict specification, and unlike later macro packages' manuals, it
does not offer an explicit list of formatter requests that are "safe" to
use with it.

In areas where a system is not specified, divergence can be expected
among multiple implementations.

Further, the `DD` display distance, at issue here, register was not even
a feature of Lesk/AT&T ms, but an innovation by 4.2BSD.  The relevant
paper for this is by Tuthill.[2]  It also did not mention how it
interacted with no-space mode, nor with how vertical spacing was
expected to accumulate (or not) with inter-paragraph spacing or spacing
before section headings.

See <https://savannah.gnu.org/bugs/?64531>.

Decisions had to be made.  I made ones that made groff render Kernighan
& Cherry's "Typesetting Mathematics" paper render reasonably well.[3]

>   Macros for historical documents should be put into a separate
> directory (e.g., tmac/historical), which can then be searched
> with the '-M <directory>' option.

If someone wants to contribute precise work-alikes for historical
implementation of macro packages, we have a mechanism and place for
that--the "contrib" directory, and it can be accessed as you describe.

But someone has to step up, do the work, and do it conscientiously.
Among other matters, they should employ a GPL-compatible Free Software
license if they want groff to adopt it, and they should avoid
plagiarizing historical macro package implementations.

>   The user should have control, not a committer.

The user _has_ control.  groff is Free Software.  You know this because
you maintain your own private fork of groff, and your failure to measure
the GNU version of it has led you repeatedly to file defect reports that
are inapplicable to GNU groff, arising from observations you make of
your own changes.[4]

>   Read the "mission statement" in
> https://www.gnu.org/software/groff/

I'm familiar with it.  If you mean to charge me with infidelity to its
objectives, you are going to have to be specific regarding which goal
you feel I have frustrated.  If you can't do that, then your attempt at
deploying it to lend your argument weight is counterfeit.

Regards,
Branden

[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/msmacros/ms
[2] 
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/doc/msmacros/ms.diffs
[3] https://github.com/g-branden-robinson/retypesetting-mathematics
[4] 
https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&summary=bjarnigroff&submitted_by=0&resolution_id=0&assigned_to=0&bug_group_id=0&status_id=0&severity=0&category_id=0&plan_release_id=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=24&history_date_monthfd=1&history_date_yearfd=2024&chunksz=50&spamscore=5&boxoptionwanted=1#options

signature.asc
Description: PGP signature