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-04T01:17:53+0100, Deri wrote:
> On Thursday, 3 October 2024 22:18:23 BST G. Branden Robinson wrote:
> > At 2024-10-03T20:58:34+0100, Deri wrote:
> > > An example is the utp document which a lot of people on this list
> > > put together. Neither the original 1.0, producing postscript, nor
> > > 1.1, producing a pdf, now build properly, from
> > > https://github.com/larrykollar/ Unix-Text-Processing.
> > > 
> > > Various problems occur using current git groff, from extra blank
> > > pages, text which was set as mono spaced appearing as Times-Roman,
> > > pdf bookmarks jumping to the wrong page, input line numbers
> > > appearing in the output (1.0 postscript only - also affects 1.23.0
> > > - Ok in 1.22.4).
> > 
> > Quite the litany: groff 1.23.0 spent 4½ years in development, has
> > been out for 15 months, had 5 release candidates before that, and
> > I'm only _now_ hearing about _any_ of this?
> 
> Only the visible line numbers issue is present in 1.23.0, the others
> are current git only. Also, I very rarely build UTP 1.0 so I did not
> spot the issue before, it was only because I wanted to rule out the
> other issues being due to something in the code I added to UTP 1.1
> that I went back to postscript version. If you build the 1.0
> postscript the numbers in the left margin start on page 403 and
> continue to the end.
> 
> The more important issues are definitely post 1.23.0.
> 
> > > Are all of these changes in behaviour really fixes to bugs in
> > > groff?
> > 
> > Impossible to say with the minimal information I have at present.
> > Each must be considered on a case-by-case basis.
> 
> 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 switch to Times-Roman from the requested mono-spaced font is down
> to commit 1d8452fb2ae3afd9bb8cb8a7f7f31741d41e85da.

I'll need to see what the document is asking for, then (I confess I
haven't paid attention to UTP recently because it seemed like it got
kind of stuck for a while and I stopped checking up on it--sorry), but
if one asks for fonts that don't exist, one shouldn't expect to get
them.  That's a NEWS item.

*  The device-specific macro files loaded by "troffrc" automatically on
   startup, such as "ps.tmac" and "html.tmac", no longer perform font
   translations for font names used by varieties of AT&T troff ('C',
   'Hb', 'HX', and many others).  These names are not portable: in AT&T
   troff, the font repertoire, like the special character repertoire,
   was device-dependent.  Since groff 1.23.0, GNU troff diagnoses
   attempts to use nonexistent font names.  We recommend addressing such
   portability issues wherever suits you: (1) in a document, perhaps by
   using `ie` and `el` requests and the `.g` register to test whether
   the formatter claims support for groff extensions, then `ie` and `el`
   again with the `F` groff conditional expression operator to check for
   font availability, and performing font remappings with the groff
   `ftr` request as desired; (2) doing so in your "troffrc" file; or (3)
   by modifying these macro files similarly.  Users of the "dvi" and
   "lbp" output devices should be aware that these devices don't supply
   full families of monospaced fonts (and never have).  See grodvi(1)
   and grolbp(1).

That leaves the line numbering issue.  I'll have a look.

Regards,
Branden

signature.asc
Description: PGP signature