Re: Regressions in UTP document (was: removing the .IX macro from the ms package in 1.23 breaks old documents)

[G. Branden Robinson]

Hi Deri,

At 2024-10-04T16:41:19+0100, Deri wrote:
> > > The extra blank pages and the erroneous bookmarks are probably
> > > linked and seem to be caused by commit
> > > 5808f3f4dd8f39341170597363a6aaf7acf921fd, which was a fix to a
> > > regression introduced into 1.23.0.
> > 
> > Ah, you in fact already reported this.  (Thanks!)  And I thought I
> > fixed it in 931da6d4d0 (5 June, this year.).  What's the status?
> > Does the fix not work?
> 
> The fix in June did fix the original problem with page breaks in the
> FBDL document that Michał was working on, but does not fix the problem
> with UTP.

Okay.  As noted earlier today, the latter problem is fixed now.

> As an aside, were you aware that FBDL has now moved away from groff
> and is using typst instead[1].

I was, but had forgotten about it, and had to refresh myself on what
FBDL was.

> Must have been a lot of work to port to another system, I wonder if we
> should reach out to Michał and find out his reasons for changing.

Not a bad idea.  Would you like to email him to conduct this...hmm...
...exit interview?

> I did wind his git back to the point just before the switch to typst
> and ran with the current groff and received 1198 font errors which
> were not present in previous groff versions,

They're warnings, not errors.

troff:build/FBDL.ms:2740: warning: cannot select font 'C'

> I don't know if this had a bearing on his decision, but it must be
> annoying when the goalposts keep changing and new versions are
> incompatible with previous releases,

...except this is a terrible example of that.  Why?  Here's the change.

commit 1986da1d4bb11dc0421e004b153729b3d2a2a3ca
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 7aeb5bd22..c564ebc82 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -1202,10 +1202,13 @@ void font_change()
        break;
       }
   }
+  // environment::set_font warns if a bogus mounting position is
+  // requested.  We must warn here if a bogus font name is selected.
   if (is_number)
-    curenv->set_font(atoi(s.contents()));
+    (void) curenv->set_font(atoi(s.contents()));
   else
-    curenv->set_font(s);
+    if (!curenv->set_font(s))
+      warning(WARN_FONT, "cannot select font '%1'", s.contents());
   skip_line();
 }

diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 5a299121d..8aadc243a 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -2052,10 +2052,16 @@ void token::next()
          for (p = s.contents(); *p != '\0'; p++)
            if (!csdigit(*p))
              break;
-         if (*p || s.is_empty())
-           curenv->set_font(s);
+         // environment::set_font warns if a bogus mounting position is
+         // requested.  We must warn here if a bogus font name is
+         // selected.
+         if (*p != 0 /* nullptr */ || s.is_empty()) {
+           if (!curenv->set_font(s))
+             warning(WARN_FONT, "cannot select font '%1'",
+                     s.contents());
+         }
          else
-           curenv->set_font(atoi(s.contents()));
+           (void) curenv->set_font(atoi(s.contents()));
          if (!compatible_flag)
            have_input = 1;
          break;

A careful perusal reveals that _absolutely nothing_ changed about
rendering here.  That is, no behavior change.  Nada.

This breaks compatibility with zilch.

Previously, if GNU troff couldn't switch to the font you asked for, it
silently failed.  Now, it still fails.  But not silently (unless you
specify `-Wfont`).

A whole bunch of diagnostic spew _can_ be alarming.  But these 1198
warnings are 1198 _counterexamples_ of groff being _incompatible_ with
previous releases.

> particularly when there is no deprecation of previous "valid" roff to
> warn of an upcoming change, but bang into an error which affects the
> output.

How is the output affected in the foregoing 1198 examples?

> I am certainly not against changes to groff, but I do think when we do
> alter groff in some way which will affect the typesetting of existing
> documents

...which the font warning change wasn't...

> it is good manners to deprecate the change before making it an error
> which will alter the way the document appears.

If you were to say that some grief might have been avoided if groff
1.23.0 had included a banner at the top of its NEWS entry/release notes
like 1.18.0 did...

************************************************************************
 PLEASE READ THE CHANGES BELOW REGARDING GROTTY, GROFF'S TTY FRONTEND.
************************************************************************

...perhaps more like...

************************************************************************
         PLEASE READ THE CHANGE BELOW REGARDING FONT WARNINGS.
               RENDERING HAS NOT CHANGED IN THIS RESPECT.
************************************************************************

...then I would not contradict you.  It's apparent to me in hindsight
that this change to diagnostic messages discomfited more people than I
anticipated.  I had not realized how many people threw no-op font
changes into their documents without ever noticing that they didn't do
anything.  The overlap between code golfers and *roff document authors
would thus appear to be small.

Is such a banner worth adding now?

Michał switched to typst for reasons he did not disclose to us.  We
didn't even get a parting bug report.  That doesn't fit the model of
ragequitting.  Possibly he acquired a professional sponsor/patron of
FBDL and that patron's selection of typesetting system was a condition
of compensation.  Or maybe he was simply excited to try something new.

Ultimately, neither Michał's choice of typesetting software nor 1,198
font warnings are valid arguments for or against any behavior change in
how groff renders documents.  The former is simply not in evidence, and
the latter is refuted by it.

What is now known as Savannah #66290 _is_ an argument against my
threshold of conservatism for code changes that affect rendering, I will
concede.  You made the first known report of that issue, in initially
vague terms,[2] on Thu, 03 Oct 2024 20:58:34 +0100, and I had landed a
fix by Fri, 4 Oct 2024 05:54:26 -0500, with multiple status updates in
the interim.

I'm curious to know on what basis you consider that a manifestation of
unsatisfactory software maintainership.

As ever,
Your student,
Branden

[1] https://lists.gnu.org/archive/html/groff/2024-10/msg00017.html

[2] "input line numbers appearing in the output (1.0 postscript
    only - also affects 1.23.0 - Ok in 1.22.4)."

    They weren't "input line numbers", but the undesired reactivation of
    output line numbering, with continued incrementation of output line
    numbers set up by an example of `nm` request usage in a previous
    chapter of the document, and the problem had nothing to do with the
    selection of output device, PostScript or otherwise.

signature.asc
Description: PGP signature