Releasing groff 1.23.0?

[G. Branden Robinson]

Hi folks,

I said I'd follow up on my personal set of fish to fry, so here we go.

We missed the release freeze for the next Debian stable release, which
may be a parochial concern of mine, but I'm sad nevertheless... :(

At 2020-10-10T20:56:49+1100, G. Branden Robinson wrote:
> We have a formal expression of interest in a new release.
> 
> https://savannah.gnu.org/bugs/?59216
[...]
> [1] My list of things I'd prefer to get accomplished before a 1.22.5
> "final" is something like this:
> 
> A. Fix #59106.  mdoc doesn't emit a partially-collected output line
>    before switching to the next file.

Fixed.

> B. Implement CT and CS register support (from groff_man(7)) in our
> mdoc.

Done.

> C. Kill off our ditroff(7) page.

Not done, not a blocker.

> D. Rename an-old to an-std, since it implements the de facto standard
>    man macros from Version 7 Unix (1979).  "-old" implies that the
>    implementation is legacy, and while I'm sure mdoc fans feel that
>    way, it's not reflective of affairs in Linux.  It could
>    alternatively imply that an-old is not actively maintained, as
>    doc-old isn't, but I reckon I'm actively maintaining our man(7)
>    implementation.

Not done, not a blocker, still want to do it.  Yell now if opposed.

> E. Deprecate the .OP man(7) macro and stop using it in our own pages.
>    It's not actually a GNU extension, but one of _many_ extensions
>    (some ill-conceived) from Documenter's Workbench 3.3 (or earlier).
>    It does nothing that can't be achieved with two-font macros and
>    doesn't support GNU-style long options, so is insufficiently
>    adaptable to real-world contemporary systems.

Not done, not a blocker, still want to do it.  Yell now if opposed.

> F. Fix the problem with man(7) .SY macros and HTML output.

Not done, not sure how to do it without effectively un-deprecating .HP,
and as far as I can tell the main reason .HP is deprecated at all is
because it was too hard to support in HTML output.  A big question mark.

> G. Decide whether it's worth implementing .MR for man(7) after Plan 9
>    just to "get it out there", or wait until I've learned enough about
>    devtags to give it a full implementation that will produce links in
>    PDF and HTML output.  The cheaper implementation would simply be a
>    semantic wrapper around a two-font macro.  The font for the page
>    name would be in a user-configurable string (like HF is today), so
>    people will stop having arguments over whether the cross-references
>    should be in bold or italic.

Not done, not a blocker, still want to do it.  Yell now if opposed.

> H. Integrate my pending "introduction to roff concepts" which I have
>    in progress as a rewrite of the first section of the "gtroff
>    Reference" chapter of our Texinfo manual.  It's my intention to
>    adapt this material to serve as a conceptual introduction in
>    roff(7) and groff_man_style(7) as well.  Right now it is written as
>    an introduction for readers who want to go straight to "raw" troff
>    without knowing much or anything about existing macro packages, but
>    my opinion at the moment is that fairly little needs to be changed
>    for the aforementioned adaptations.  I'm attaching the
>    work-in-progress for the curious.  Feedback welcome.

Done.  This is now the beginning of chapter 5 of our Texinfo manual.

> I. Get the ms.ms document current at _least_ with what's in our
>    Texinfo manual, and preferably with our actual ms implementation,
>    and drop that chapter from our Texinfo manual as discussed some
>    months ago.

In progress but not done yet.  There's a lot more to ms's history than I
imagined or have seen any other document discuss.  Thanks to Doug
talking about an ms .FL macro, I discovered that there's a dialectal
difference between Version 6 Unix ms and Version 7.  Would be good to
complete this but the resurrected ms.ms is already significantly updated
and improved in accuracy.  I don't intend to retire the Texinfo section
or add a NEWS item for ms.ms (though it is mentioned in passing already)
until the work is done.

> J. Regenerate the AFM metrics and add this step to our FOR-RELEASE
>    document.  Also figure out if we should be using/embedding URW font
>    metrics instead.  Funny things happen when I try to draw boxes
>    around some glyphs in Times roman and I think it's because the
>    metrics are wrong.

Not done and not likely to be done because I don't have access to
Adobe's proprietary fonts or someone who can tell me that URW's metrics
really are identical.

Moreover, once this kind of thing can be done, it's worth scripting and
then supporting a tool for it, so that "download" files and other stuff
like that can be generated by distributor packages on the target system
instead of just on a build host.  A similar issue is that we're tightly
coupled to GhostScript releases because they keep changing the names of
fonts.  Deri reliably catches us up, but this issue can throw
distributors out of sync, forcing cherry-picked backported patches and
rebuilds[1].  Another bird killable with this stone, I think, is Dorai
Sitaram's suggestion to provide groff Unicode special character mappings
for Zapf Dingbats fonts[2] (since it is information from "outside" the
font that groff is adding for its own benefit, like additional kerning
pair definitions[3]).

The boxed glyph thing is something I should get around to reproducing
and filing a bug report for.

> K. Maybe #58796.  This is actual development work, so might not make
> it.

Not done, not a blocker, and not likely in the immediate future.  (It's
a feature I want to add giving preconv(1) options to produce AT&T \(xx
and groff \[xxx] special character escapes when they exist, instead of
spitting out Unicode-style escapes \[unnnn] for all non-ASCII code
points.)

I should add some further items.

L. Incorporate Deri's shaded box PDF/ms feature from the
   dev-gropdf-boxes branch.

M. Earn the wrath of up to every BSD user on the planet by introducing a
   man(7) register called GROFF_DEGRADE_UTF8_GLYPHS or something, and
   have it off by default.  I remain as unpersuaded as my opponents in
   this knock-down drag-out argument[4].  We have .soquiet now, so I
   propose to tell people to make a $HOME/.troffrc or
   $XDG_CONFIG_HOME/troffrc, alter the system troffrc to read it (we
   could do this ourselves), and curse my name while mashing poor
   unoffending -, `, and ', input characters into ASCII code points with
   .char requests in those files.  See "Fundamental character set" in
   groff_char(7) for background[5].

N. I regressed tbl(1) support for some complicated applications of line
   numbering (which became supported in 2011) in the course of fixing a
   simple one pointed out last year[6].  I need to file a Savannah
   ticket for this.  This is my biggest regret and philosophically the
   worst potential blocker known to me.  I was well-motivated to work on
   this but have so far been defeated by the cleverness of George
   Helffrich's implementation in spite of his generous provision of a
   précis of the underlying problems.

O. I want to add brackets [] around automatic footnote numbers in ms in
   nroff mode, for compatibility with Heirloom Doctools ms and a big
   readability improvement.  As a stretch goal, make the footnote marker
   opening and closing symbols configurable with strings, maybe FNM1 and
   FNM2.  I'll probably do this next time I cycle back to ms tasks.

Assistance, critique, and disputation are welcome, as always.  (If
commenting on a specific point, you might want to update the Subject:).

Regards,
Branden

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982302
    Also see [7].
[2] https://lists.gnu.org/archive/html/groff/2021-01/msg00059.html
[3] https://lists.gnu.org/archive/html/groff-commit/2021-01/msg00017.html
[4] https://lists.gnu.org/archive/html/groff/2020-10/msg00158.html
    https://lists.gnu.org/archive/html/groff/2020-11/msg00001.html
[5] https://man7.org/linux/man-pages/man7/groff_char.7.html
[6] https://lists.gnu.org/archive/html/groff/2021-02/msg00085.html
[7] https://lists.gnu.org/archive/html/groff/2021-01/msg00037.html

signature.asc
Description: PGP signature