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

[Deri]

On Friday, 4 October 2024 20:21:13 BST G. Branden Robinson wrote:
> Hi Deri,
>

Hi Branden,
 
> At 2024-10-04T16:41:19+0100, Deri wrote:
> > 
> > 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.

In FBDL, but still causes the extra pages in UTP, any idea why?

> > 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?

Ok.

> > I did wind his git back to the point just1 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'

Not the only type of warning, you missed the other one.

> > 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.
> 
[snip code perusal]
> 
> A careful perusal reveals that _absolutely nothing_ changed about
> rendering here.  That is, no behavior change.  Nada.
> 
> This breaks compatibility with zilch.

I must admit I am with Tadziu here, preferring empirical observation to 
assurance of what the code is doing. This is what I ran on git and 1.23.0:-

echo "\s'+5'\f(CBBold \fCNot Bold"|groff -Tpdf -ms -P-e| okular -

I hope you can see the rendering difference, it is certainly not 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.

Well, if you had spotted that there are two types of warnings in the 1198, and 
had actually checked to see if the rendering had changed in all of them, I 
suspect you would not have written this paragraph.

> > 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?

Quite a lot, completely different font used compared to 1.23.0, see above 
example.

> > 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...

Yes, it was.

> > 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.

It could be argued that changes to typeset output, as opposed to terminal 
output, are more susceptable to cause annoyance because the document authors 
have probably taken time to get the output exactly as they want it, and the 
heading you suggest is just not true, rendering is affected.

> 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.

This is a strange statement! I have cast no aspersions about your software 
maintainership regarding "that" (the fix for #66290), in fact I have said 
nothing, although I am impressed with how quickly you tracked it down and 
fixed it. I'm pleased my report was not too vague, you found the problem just 
fine.

> 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.