Re: the Courier font family and nroff history

[Russ Allbery]

"G. Branden Robinson"  writes:

> Okay...by this time groff had for about 10 years been producing
> device-independent _terminal_ output from troff(1).  On the other, that
> is its own peculiar little language.  Maybe the author just didn't want
> to deal with *roff, or didn't want to count on GNU troff being
> available.

Oh, yeah, to be clear, the context of this was viewing Perl documentation
without nroff, so it's fairly off-topic for this list other than the
specific example of someone who found overstrike output useful in a
related context.

There has been a lot of back and forth in the Perl world about whether to
use a formatting pipeline that involves nroff by default.  perldoc
defaulted to Pod::Man plus nroff for a long time, but it's defaulted to
Pod::Text for a while.  I think the main reason was better UTF-8 support
(which is partly my fault for being very conservative about not wanting to
produce UTF-8 roff for a long time until I could do some comprehensive
testing that took me embarrassingly long to do, and people understandably
got sick of their names showing up as sequences of X characters), but
portability to Windows and some other platforms was I think part of the
reasoning.

I have to be honest that I've not kept track of that debate because I
didn't want to own the problem and I wasn't seeing the user feedback.
It's all the same to me; both Pod::Man and Pod::Text are supported and
will continue to be.  But now Pod::Man supports UTF-8 by default because I
managed to convince myself that this worked on every significant platform
that wasn't a museum piece.

I think my brain works a little oddly in that I sort of randomly use
perldoc or man to read Perl documentation so sometimes it's formatted with
nroff and sometimes it's not and I don't really notice the difference.  I
also write all my code in Emacs but use vi to write all my commit messages
and randomly switch between them for editing text files.  I am probably
not the average user.  :)

>> I know that to a first approximation all the world is now some
>> variation of an imaginary VT100 terminal emulator, and thus one can
>> usually blindly use SGR escape sequences and expect them to work in
>> much the way that one can assume all programs only run on VMS.

> I think that's a little unfair.  We can trace the history of these
> escape sequences back to ANSI X3.64, which was later succeeded by
> ECMA-48 and (equivalently, as far as I know) ISO 6429 and JIS X 0211.
> These standards have been around approximately as long as Unix has been
> something you were likely to run into at your university or workplace.

I'm sorry, I really hope that didn't sound critical of anyone here.  It
was meant to be wryly funny, but I probably shouldn't be attempting that
on a mailing list I'm fairly new to.  I am one of those people who blindly
assumes SGR escape sequences in a lot of things (I also maintain
Term::ANSIColor in Perl core), so I was mostly poking fun at myself, but I
didn't explain any of that.

I know that you of all people wouldn't blindly do anything.  :)  I just
see a ton of code out there these days that assumes everything is ECMA-48
compatible, which to be fair really is a reasonable assumption in most
places these days.  We still have all of the infrastructure to support
terminals that behave very differently, like VT-52s, and a lot of code
still calls into it, but I think the details of terminal portability are a
bit of a lost art and I bet a lot of things would not actually work on a
real VT-52.

I remember the days when you could enter your username in ALL CAPS at the
Linux console login prompt and it would automatically switch to the mode
that supported compatibility with terminals that didn't have lowercase
letters.  But there is no compelling reason to support this type of
portability any more unless one is running a museum.

> But that's not the fault of ECMA-48, which has even had the virtue of
> being freely available on the Web for many years.  We cannot say as much
> for many ANSI or ISO/IEC standards.

Yes, indeed, although as I've learned from maintaining Term::ANSIColor,
there's all sorts of new-fangled stuff now, such as "true color" support
which Wikipedia thinks comes from ITU T.416.  I never bothered to track it
down.

> I'm no MS-DOS/Windows expert, but my understanding is that you couldn't
> count on support for ECMA-48 at the DOS prompt (or equivalently in
> CMD.EXE on NT-descended Windows) because the console driver didn't
> recognize them.

Correct, although I believe this may have changed with newer versions of
Windows.

> I have gathered, by reading bug fora and similar while trawling the
> Internet for accounts of trouble with groff that people are too lazy to
> actually report to us, that Windows 10 or 11 has a console
> driver/terminal emulator that does "better" with ECMA-48 support.  I
> haven't heard even a rumor of anything usefully quantitative, like a
> table of its support for standardized escape 

Re: the Courier font family and nroff history

[G. Branden Robinson]

At 2024-03-22T22:12:08-0500, G. Branden Robinson wrote:
> (Kernighan didn't completely unify terminals under the
> device-independent troff scheme presented in CSTR #54

CSTR #97

> --nevertheless its "driving tables" for terminal devices bore a
> startling resemblance to "DESC" files for typesetting devices.)

Regards,
Branden


signature.asc
Description: PGP signature

Re: the Courier font family and nroff history

[G. Branden Robinson]

At 2024-03-22T17:06:40-0700, Russ Allbery wrote:
> "G. Branden Robinson"  writes:
> 
> > That's a good argument against grotty(1) emitting overstriking
> > sequences, at least by default, and yet that the people swiftest to
> > anger on this subject argue _for_ it.
> 
> I'm not fully following this argument, but (assuming I've not
> completely lost the train of conversation), it may be relevant here
> that some years ago (it was in 2000, which surely was only five or six
> years ago) a contributor went to the trouble of writing
> Pod::Text::Overstrike to format POD output with backspacing with
> overstrike or underscores.  At the time, a version that used termcap
> already existed (and still does).

You prompted me to take a look around at podlators Git.  I didn't have
any idea this existed.  Neat!

> The stated reason was that the output was device-independent, unlike
> output that embeds formatting codes derived from device-specific
> termcap entries,

Okay...by this time groff had for about 10 years been producing
device-independent _terminal_ output from troff(1).  On the other, that
is its own peculiar little language.  Maybe the author just didn't want
to deal with *roff, or didn't want to count on GNU troff being
available.  (Kernighan didn't completely unify terminals under the
device-independent troff scheme presented in CSTR #54--nevertheless its
"driving tables" for terminal devices bore a startling resemblance to
"DESC" files for typesetting devices.)

> and they really liked the bold and underlining rather than the plain
> text or *ad hoc* markup produced by Pod::Text.

Part of me wants to yell "then why not just use nroff, for crying out
loud", but part of me understands the fun of finding one's own way.

> I know that to a first approximation all the world is now some
> variation of an imaginary VT100 terminal emulator, and thus one can
> usually blindly use SGR escape sequences and expect them to work in
> much the way that one can assume all programs only run on VMS.

I think that's a little unfair.  We can trace the history of these
escape sequences back to ANSI X3.64, which was later succeeded by
ECMA-48 and (equivalently, as far as I know) ISO 6429 and JIS X 0211.
These standards have been around approximately as long as Unix has been
something you were likely to run into at your university or workplace.

I would never advocate _blind_ usage of SGR or other ECMA-48 escape
sequences.  For SGR in particular, even termcap has a capability code:
"sa".  Programs, including GNU Bash and those in GNU Coreutils,
_should_, in my opinion, be using termcap or (preferably) terminfo to
look before they leap.  But the cryptic form of ECMA-48 escape sequences
has proven seductive to junior hackers (in mentality, if not always
chronological age) far and wide.  As soon as they can make the terminal
jump with "printf '\e[xx;yy\a'" they get completly carried away.

Often, the next day, the same person will, in a code review, confidently
and with no sense of irony, accuse your work of a "layering violation".

Really, there isn't a hand large enough to slap these people with.

But that's not the fault of ECMA-48, which has even had the virtue of
being freely available on the Web for many years.  We cannot say as much
for many ANSI or ISO/IEC standards.

> But I have occasionally had reports that Pod::Text::Overstrike is a
> better option for (some) Windows users because apparently their pager
> handled the overstriking but termcap (via the Perl Term::Cap module)
> wasn't available.

I'm no MS-DOS/Windows expert, but my understanding is that you couldn't
count on support for ECMA-48 at the DOS prompt (or equivalently in
CMD.EXE on NT-descended Windows) because the console driver didn't
recognize them.  However, if the user told CONFIG.SYS to load ANSI.SYS,
it would, because that module interposed itself before the BIOS call
that talked to the display, and interpreted them, driving the
CGA/EGA/VGA hardware appropriately.

God, I feel dirty talking about this crap.  I'm sorry I remember even
that much.

I have gathered, by reading bug fora and similar while trawling the
Internet for accounts of trouble with groff that people are too lazy to
actually report to us, that Windows 10 or 11 has a console
driver/terminal emulator that does "better" with ECMA-48 support.  I
haven't heard even a rumor of anything usefully quantitative, like a
table of its support for standardized escape sequences in comparison
with, say, xterm, or even the Linux kernel's somewhat wobbly virtual
console device.  But, supposedly, things are "better".

> I have no idea how dated this information is, having not used Windows
> myself in several decades, but I always found it interesting.  I've
> kept the module working all these years since it's not much additional
> effort.

No crime in that.  I keep a lot of ancient groff stuff in service too.

At 2024-03-22T21:08:39-0500, Dan Plassche wrote:
> Overstrikes are more easily filtered and 

Re: the Courier font family and nroff history

[Dan Plassche]

On Fri, Mar 22, 2024 at 7:07 PM Russ Allbery  wrote:

>
> The stated reason was that the output was device-independent, unlike
> output that embeds formatting codes derived from device-specific termcap
> entries, and they really liked the bold and underlining rather than the
> plain text or *ad hoc* markup produced by Pod::Text.

Overstrikes are more easily filtered and transformed for other output
formats than levels of nested escape codes that are terminal specific.

Enscript from Adobe, and the more featureful GNU replacement, are good
examples of tools designed to work with nroff or other daisywheel/line
printer output using overstrikes.   The preformatted line and page
layout are fully retained with all overstrikes rendered properly and
the ability to use any font (converted) in the postscript output,
which is awesome for printing historical documents designed for nroff.
You can also easily pass custom roff overstrikes to simulate combined
typewriter characters beyond bold and underline.

I have no major objection to using escape sequences and agree they
open some additional possibilities for functionality in modern
terminal emulators.  However, I think that most people using
overstrikes  have less as the pager in raw mode where underlines and
bold display correctly for manual pages.  It's a shame that early pc
vga consoles did not display underlines or italics properly!  Most
other *nix platforms did, and that's really not a problem in X or
modern graphical consoles like wscons on NetBSD that display
overstrikes correclty.

Best,

Dan

-- 
Dan Plassche

Re: the Courier font family and nroff history

[Russ Allbery]

"G. Branden Robinson"  writes:

> That's a good argument against grotty(1) emitting overstriking
> sequences, at least by default, and yet that the people swiftest to
> anger on this subject argue _for_ it.

I'm not fully following this argument, but (assuming I've not completely
lost the train of conversation), it may be relevant here that some years
ago (it was in 2000, which surely was only five or six years ago) a
contributor went to the trouble of writing Pod::Text::Overstrike to format
POD output with backspacing with overstrike or underscores.  At the time,
a version that used termcap already existed (and still does).

The stated reason was that the output was device-independent, unlike
output that embeds formatting codes derived from device-specific termcap
entries, and they really liked the bold and underlining rather than the
plain text or *ad hoc* markup produced by Pod::Text.

I know that to a first approximation all the world is now some variation
of an imaginary VT100 terminal emulator, and thus one can usually blindly
use SGR escape sequences and expect them to work in much the way that one
can assume all programs only run on VMS.  But I have occasionally had
reports that Pod::Text::Overstrike is a better option for (some) Windows
users because apparently their pager handled the overstriking but termcap
(via the Perl Term::Cap module) wasn't available.

I have no idea how dated this information is, having not used Windows
myself in several decades, but I always found it interesting.  I've kept
the module working all these years since it's not much additional effort.

-- 
Russ Allbery (ea...@eyrie.org) 

Re: Running the grohtml pipeline as a pipeline

[Alejandro Colomar]

Hi Branden,

On Fri, Mar 22, 2024 at 05:45:14PM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2024-03-22T21:24:10+0100, Alejandro Colomar wrote:
> > Heh, we're comparing different things.  I'm comparing `eqn -Tps` to
> > nothing at all, while you're comparing `eqn -Tps` to `eqn -Thtml`.  If
> > I diff the same things you're diffing, then I see the same as you.
> 
> Ahh.  Okay.  Yes, I see it now and can reproduce the problem with 1.23.0
> and Git HEAD.  I'd bet it's in 1.22.4 and 1.22.3, too.

Nice.

> I've always wondered why grohtml wants to express indentation in terms
> of a percentage of available browser window[1] width.

Ahh, so if I change the window width, the indentation changes.  Funny!

> Maybe I should do with grohtml what наб accused me of doing with mdoc:

Any links to that?  Sounds like a funny discussion.  :D

> just stick my fingers in and start poking.  I hadn't imagined that
> anyone was actually _fond_ of groff mdoc(7)'s typographical choices on
> typesetters, but I was mistaken.  With grohtml, there may be some, but
> there's concrete evidence that a lot of people weren't.

I was actually a bit surprised that Paul Eggert mentioned grohtml(1) as
an improvement over man2html(1).  While man2html(1) is ancient and quite
bad... grohtml(1) output is on par with that.  Let's improve that!  :)

> Regards,
> Branden
> 
> [1] or whatever the proper name for it is in HTML standardese

Have a lovely night!
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Re: Running the grohtml pipeline as a pipeline

[G. Branden Robinson]

Hi Alex,

At 2024-03-22T21:24:10+0100, Alejandro Colomar wrote:
> Heh, we're comparing different things.  I'm comparing `eqn -Tps` to
> nothing at all, while you're comparing `eqn -Tps` to `eqn -Thtml`.  If
> I diff the same things you're diffing, then I see the same as you.

Ahh.  Okay.  Yes, I see it now and can reproduce the problem with 1.23.0
and Git HEAD.  I'd bet it's in 1.22.4 and 1.22.3, too.

I've always wondered why grohtml wants to express indentation in terms
of a percentage of available browser window[1] width.

Maybe I should do with grohtml what наб accused me of doing with mdoc:
just stick my fingers in and start poking.  I hadn't imagined that
anyone was actually _fond_ of groff mdoc(7)'s typographical choices on
typesetters, but I was mistaken.  With grohtml, there may be some, but
there's concrete evidence that a lot of people weren't.

Regards,
Branden

[1] or whatever the proper name for it is in HTML standardese


signature.asc
Description: PGP signature

Re: An extremely lazy proposal

[G. Branden Robinson]

Hi Oliver,

At 2024-03-22T21:01:27+0100, Oliver Corff via wrote:
> recently I compiled, and re-compiled, and again recompiled a set of
> various documents with different tables, equations etc.. For each of
> the documents, the precise requirements of preprocessors were
> different, and more often than not, I forgot to set the appropriate
> groff option when running the compilation to the effect that I had to
> redo my edit - check cycle.

I second Dave's suggestion that what you want _here_ is a Makefile.  Why
struggle to remember what invocation is required when you can record it
in a reliable script?  Since I have it handy, I'll attach Stuart
Feldman's original make(1) paper from Seventh Edition Unix.

> Since there is no groffer script anymore, may I humbly propose a new
> option to groff, namlely "-A" (mnemomic: [A]ll preprocessors) which
> forces all available preprocessors to be used?

My view is expressed in groff(1):

   To process a roff input file using the preprocessors tbl and pic
   and the me macro package in the way to which AT troff users
   were accustomed, one would type (or script) a pipeline.

  pic foo.me | tbl | troff -me -Tutf8 | grotty

   Using groff, this pipe can be shortened to an equivalent command.

  groff -p -t -me -T utf8 foo.me

   An even easier way to do this is to use grog(1) to guess the
   preprocessor and macro options and execute the result by using
   the command substitution feature of the shell.

  $(grog -Tutf8 foo.me)

You might therefore define a couple of functions in your .bashrc or
similar shell startup file.

# format for typesetter
gr () {
$(grog -T pdf "$@")
}

# format for terminal
grt () {
$(grog -T utf8 "$@")
}

> The penalty of this display of laziness is, in my eyes, minor: running
> a document against a preprocessor which is not needed does not do any
> harm I am aware of (I stand to be corrected in case there is such a
> situation), and since we talk only of a handful of preprocessors, not
> dozens, the overhead in CPU time should also be acceptable; all the
> more since -A would be invoked only in case of the presumed presence
> of any of tables, equations, pictures, reference lists.

I agree that even the accumulated cost of repeated unnecessary
preprocessor runs is likely low on modern systems.  But I also think
that combining the "groff guesser" with features extant in nearly every
Unix shell enable people to be lazy in ways that they can tailor to
their needs.

> I am ready to accept the appropriate reprimand for this idea.

I don't think a reprimand is warranted for seeking to economize your
personal workflow.  Much of the power of Unix comes from the way it
encourages the user to compose independent code modules, including
entire programs, in ways that you can fine-tune.  One of the virtues of
a mailing list like this is that we can share, refine, and adapt tips
and tricks for doing so.

Regards,
Branden


feldman.pdf
Description: Adobe PDF document


signature.asc
Description: PGP signature

Re: An extremely lazy proposal

[Dave Kemper]

I don't have any complaint with your proposal, but it sounds like what
you need is a makefile or script to insure groff runs are done the
same way every time.  More simplistically, you can define a shell
alias to invoke all preprocessors: "alias groff='groff -k -e -p -t
-R'".  (Or name the alias something like "allgroff" if you want to
easily be able to run the nonaliased groff sometimes.)

A switch to run all preprocessors still won't catch other necessary
command-line options, like macro packages.

Re: An extremely lazy proposal

[Peter Schaffter]

On Fri, Mar 22, 2024, Oliver Corff via wrote:
> Dear All,
> 
> recently I compiled, and re-compiled, and again recompiled a set of
> various documents with different tables, equations etc.. For each of the
> documents, the precise requirements of preprocessors were different, and
> more often than not, I forgot to set the appropriate groff option when
> running the compilation to the effect that I had to redo my edit - check
> cycle. Since there is no groffer script anymore, may I humbly propose a
> new option to groff, namlely "-A" (mnemomic: [A]ll preprocessors) which
> forces all available preprocessors to be used? The penalty of this
> display of laziness is, in my eyes, minor: running a document against a
> preprocessor which is not needed does not do any harm I am aware of (I
> stand to be corrected in case there is such a situation), and since we
> talk only of a handful of preprocessors, not dozens, the overhead in CPU
> time should also be acceptable; all the more since -A would be invoked
> only in case of the presumed presence of any of tables, equations,
> pictures, reference lists.

I preview all my groff files with a mapped key in vim(1).  The key
invokes a script that throws -Kutf8 -e -t -p -R -s -G at groff
regardless of which preprocessors are needed, if any.  I've never
noticed a performance penalty.  The -A option might be a good idea.

-- 
Peter Schaffter
https://www.schaffter.ca

Re: Milestone reached: hyperlinked mdoc(7) documents in PDF

[Deri]

On Friday, 22 March 2024 16:59:14 GMT Alejandro Colomar wrote:
> ow, how am I supposed to
> get that patch without anyone tampering it during its trip to my
> computer?  :(

derij@ws:~$ md5sum  /var/www/chinese.patch.gz 
109e2681b7402ca55118226aa575b6d3  /var/www/chinese.patch.gz

Re: An extremely lazy proposal

[Lennart Jablonka]

Quoth Oliver Corff via:

Reply-to:  Oliver Corff 


This might not be the greatest of ideas.  An MUA might just decide 
to reply to you only, instead of to you and the list.



Dear All,

recently I compiled, and re-compiled, and again recompiled a set of
various documents with different tables, equations etc.. For each of the
documents, the precise requirements of preprocessors were different, and
more often than not, I forgot to set the appropriate groff option when
running the compilation to the effect that I had to redo my edit - check
cycle. Since there is no groffer script anymore, may I humbly propose a
new option to groff, namlely "-A" (mnemomic: [A]ll preprocessors) which
forces all available preprocessors to be used? The penalty of this
display of laziness is, in my eyes, minor: running a document against a
preprocessor which is not needed does not do any harm I am aware of (I
stand to be corrected in case there is such a situation), and since we
talk only of a handful of preprocessors, not dozens, the overhead in CPU
time should also be acceptable; all the more since -A would be invoked
only in case of the presumed presence of any of tables, equations,
pictures, reference lists.


There is such a situation, where running all available 
preprocessors can do harm:  soelim expands .so requests, but does 
so unconditionally, even if the .so is inside conditional text or 
a macro definition or whatnot.


I recently ran into this before noticing that groff’s -I option 
implies -s while trying OpenBSD’s remnant -mdoc (in 
/usr/src/share/tmac/mdoc).  Unlike Groff’s -mdoc, OpenBSD’s -mdoc 
does not indent the .so line in the definition of .Hf (which wraps 
.so).  And so soelim complained about not being able to find 
a file “\\$1.”

Re: the Courier font family and nroff history (was: mandoc(1)'s man pages, groffed, and Project KIC)

[Lennart Jablonka]

Quoth G. Branden Robinson:

At 2024-03-19T19:59:58+, Lennart Jablonka wrote:

Right.  We can emulate the nonsense typewriter /emulators/ do.  I do
think that we shouldn’t do that, either.


I would not describe character-cell video terminals as "typewriter
emulators" precisely because they don't emulate typewriters well in
certain respects.  The most obvious of these is that CCVTs, if you will,
don't overstrike.


Right.  Not typewriter emulators, then, but typewriter emulator 
emulators.  I don’t think we need to emulate typewriter emulator 
emulators.


.Sarcasm
What’s next?
Should the printed book of Groff man pages be read with 300 baud?
If I don't understand something, should I send a break signal,
for the book to switch to a different baud rate?
.EndSarcasm


Back in the cradle, at the Bell Labs CSRC, the team famously pursued a
human-computer interface gambit, skipping over so-called "glass TTYs"
altogether, leapfrogging from paper terminals to a Xerox PARC-esque
portrait-mode green screen graphical terminal with mouse called,
variously, the "Jerq", the "Blit", and "DMD 5620".  In the Eighth
Edition Unix manual you can read much about the intended interface to
this device.  Rob Pike's fingerprints coated this system thoroughly.


While I never used a hardware Blit, I have used both Plan 9 and 
its device multiplexer rio(1), whose interface is very similar to 
mpx/mux, and 9front’s Blit-emulator with an 8th Edition VM.  
Coming from the Plan 9 world, it’s always fun to read how much of 
what we think of special of Plan 9 appeared in Research Unix’s 
last three editions.  Beside the other stuff there.


Late Research Unix had both troff and TeX in use, but did you know 
about its own new typesetting program, monk?


https://www.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/monk/monk.m


That is why I value and appreciate your patch to make grotty a
terminfo(3) application, even though I'm slow as hell to integrate it.

Yes, I probably would move a little faster if I didn't spend entire
mornings composing emails like this one.  :-|


Not to worry: While I do wish for upstream grotty to use terminfo 
soon, I also enjoy reading your emails like that one.



At 2024-03-22T13:24:04-0500, G. Branden Robinson wrote:
and video terminals emulated typewriters well enough for unserious
work like formatting man pages on a screen.


Err, this is pretty hugely false.

They didn't.

That's why you had to pipe nroff's output through col(1) or ul(1).

This fact got obscured, including from me just now, by the fact that
some pager programs took it upon themselves to interpret backslashes in
their input streams.  Probably because that's what the Teletype Model
37-oriented nroff produced for man pages, which lots of people read on
their video terminals.


… backslashes?  You might mean backspaces.  Or perhaps reverse 
line feeds.


If you mean backspaces: No, I think man pages are readable enough 
even without emboldening and underlining.  I feel like defending 
Plan 9, you understand.  Its nroff does emit reverse line feeds 
for occasions like two-column output, but it does not emit 
backspaces for bold and underlined text, as far as I can tell.  
When using the man(1) script to view man pages using nroff, you 
aren’t gonna get any font changes in your rio layer.


With which we’re back at the Jerq/Blit and its heritage: While 
nroff did not gain terminfo support in 1127 because they had 
a graphics system that, being superior to glass typewriter 
emulators, did not understand ACME-48-esque escape sequences.  But 
even with that graphics system—that sure had proof(9)—they chose 
to read man pages on-line without bold and underlined text.


I’m afraid I’m not intimately familiar with the man page-reading 
process at 1127.  I don’t know how many dead tree volumes were 
flying around or how much they used man -T.


[proof(9)]: https://www.tuhs.org/cgi-bin/utree.pl?file=V10/man/man9/proof.9

Re: Running the grohtml pipeline as a pipeline

[Alejandro Colomar]

On Fri, Mar 22, 2024 at 03:15:11PM -0500, G. Branden Robinson wrote:
> At 2024-03-22T20:56:28+0100, Alejandro Colomar wrote:
> > I'm quite surprised that you aren't even getting the warning due to
> > `eqn -Thtml`.
> 
> I did.  I elided it.  I also elided nearly all of my garrulous shell
> prompt.  ;-)
> 
> > I was running
> > 
> > $ troff --version
> > GNU troff (groff) version 1.23.0.902-1fce7-dirty
> > 
> > But I can reproduce it with 1.23.0:
> 
> Well, let me see if I can...
> 
> Nope.  Still can't.

Heh, we're comparing different things.  I'm comparing `eqn -Tps` to
nothing at all, while you're comparing `eqn -Tps` to `eqn -Thtml`.  If I
diff the same things you're diffing, then I see the same as you.

$ diff -u0 \
<(/usr/bin/preconv man3/_Generic.3 \
| /usr/bin/tbl \
| /usr/bin/eqn -Tps \
| /usr/bin/troff -man -Thtml -Wbreak \
| /usr/bin/post-grohtml) \
<(/usr/bin/preconv man3/_Generic.3 \
| /usr/bin/tbl \
| /usr/bin/eqn -Thtml \
| /usr/bin/troff -man -Thtml -Wbreak \
| /usr/bin/post-grohtml);
warning: /usr/bin/eqn should have been given a '-Tps' option
warning: (it is advisable to invoke groff via: groff -Thtml -e)
$ echo $?
0

Cheers,
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Re: Running the grohtml pipeline as a pipeline

[G. Branden Robinson]

At 2024-03-22T20:56:28+0100, Alejandro Colomar wrote:
> I'm quite surprised that you aren't even getting the warning due to
> `eqn -Thtml`.

I did.  I elided it.  I also elided nearly all of my garrulous shell
prompt.  ;-)

> I was running
> 
>   $ troff --version
>   GNU troff (groff) version 1.23.0.902-1fce7-dirty
> 
> But I can reproduce it with 1.23.0:

Well, let me see if I can...

Nope.  Still can't.

$ preconv man3/_Generic.3 | tbl | eqn -Thtml | troff -man -Thtml -Wbreak | 
post-grohtml >| _Generic-eqn-Thtml.html
warning: eqn should have been given a '-Tps' option
warning: (it is advisable to invoke groff via: groff -Thtml -e)
$ preconv man3/_Generic.3 | tbl | eqn -Tps | troff -man -Thtml -Wbreak | 
post-grohtml >| _Generic-eqn-Tps.html
$ stat -c '%s %n' _Generic-eqn-T*
2999 _Generic-eqn-Thtml.html
2999 _Generic-eqn-Tps.html
$ diff -u _Generic-eqn-T*
--- _Generic-eqn-Thtml.html 2024-03-22 15:11:43.337162821 -0500
+++ _Generic-eqn-Tps.html   2024-03-22 15:11:31.777158605 -0500
@@ -1,5 +1,5 @@
 
-
+
 http://www.w3.org/TR/html4/loose.dtd;>
 

Something is interfering with your installation, I think.  Maybe try a
different system/VM/chroot.  Or temporarily uninstall groff-Git (that's
what I did to produce the foregoing, to ensure the groff in
~/bin/groff-stable rather than ~/bin/groff-HEAD would be found).

Regards,
Branden


signature.asc
Description: PGP signature

An extremely lazy proposal

[Oliver Corff via]

Dear All,

recently I compiled, and re-compiled, and again recompiled a set of
various documents with different tables, equations etc.. For each of the
documents, the precise requirements of preprocessors were different, and
more often than not, I forgot to set the appropriate groff option when
running the compilation to the effect that I had to redo my edit - check
cycle. Since there is no groffer script anymore, may I humbly propose a
new option to groff, namlely "-A" (mnemomic: [A]ll preprocessors) which
forces all available preprocessors to be used? The penalty of this
display of laziness is, in my eyes, minor: running a document against a
preprocessor which is not needed does not do any harm I am aware of (I
stand to be corrected in case there is such a situation), and since we
talk only of a handful of preprocessors, not dozens, the overhead in CPU
time should also be acceptable; all the more since -A would be invoked
only in case of the presumed presence of any of tables, equations,
pictures, reference lists.

I am ready to accept the appropriate reprimand for this idea.

Best regards,

Oliver.

--

Dr. Oliver Corff
Mail:oliver.co...@email.de

Re: Running the grohtml pipeline as a pipeline

[Alejandro Colomar]

Hi Branden,

On Fri, Mar 22, 2024 at 02:44:26PM -0500, G. Branden Robinson wrote:
> At 2024-03-22T20:10:51+0100, Alejandro Colomar wrote:
> > It reduces the base paragraph inset (did I use the right term? :) to
> > almost nothing.
> 
> I have to say I regard this as a pretty minor problem compared to others
> I've seen grohtml have with man pages.
> 
> However, I would also say that it's wrong that running eqn on an input
> document that doesn't even _use_ eqn should change anything about the
> rendering.  That's weird.
> 
> ...and it turns out I can't reproduce this.
> 
> $ preconv man3/_Generic.3 | tbl | eqn -Thtml | troff -man -Thtml -Wbreak | 
> post-grohtml >| _Generic-eqn-Thtml.html

I'm quite surprised that you aren't even getting the warning due to
`eqn -Thtml`.

> $ preconv man3/_Generic.3 | tbl | eqn -Tps | troff -man -Thtml -Wbreak | 
> post-grohtml >| _Generic-eqn-Tps.html
> $ stat -c '%s %n' _Generic-eqn-T*
> 3010 _Generic-eqn-Thtml.html
> 3010 _Generic-eqn-Tps.html
> $ diff -u _Generic-eqn-T*
> --- _Generic-eqn-Thtml.html 2024-03-22 14:32:37.651496863 -0500
> +++ _Generic-eqn-Tps.html   2024-03-22 14:32:24.779577657 -0500
> @@ -1,5 +1,5 @@
>  
> -
> +
>"http://www.w3.org/TR/html4/loose.dtd;>
>  
> 
> I can't think of anything in the last 179 commits that would have
> affected this, but...179 slightly exceeds the capacity of human working
> memory.

I was running

$ troff --version
GNU troff (groff) version 1.23.0.902-1fce7-dirty

But I can reproduce it with 1.23.0:

$ /usr/bin/groff --version | head -n1;
GNU groff version 1.23.0
$ diff -u0 \
<(/usr/bin/preconv man3/_Generic.3 \
| /usr/bin/tbl \
| /usr/bin/eqn -Tps \
| /usr/bin/troff -man -Thtml -Wbreak \
| /usr/bin/post-grohtml) \
<(/usr/bin/preconv man3/_Generic.3 \
| /usr/bin/tbl \
| /usr/bin/troff -man -Thtml -Wbreak \
| /usr/bin/post-grohtml);
--- /dev/fd/63  2024-03-22 20:51:15.333130375 +0100
+++ /dev/fd/62  2024-03-22 20:51:15.333130375 +0100
@@ -38 +38 @@
-_Generic 
+_Generic 
@@ -47 +47 @@
-_Generic(expression,
+_Generic(expression,
@@ -57 +57 @@
-_Generic()
+_Generic()
@@ -64 +64 @@
-expression
+expression
@@ -67 +67 @@
-This is
+This is
@@ -77 +77 @@
-C11.
+C11.
@@ -84 +84 @@
-C11.
+C11.
@@ -91 +91 @@
-The following
+The following
@@ -97 +97 @@
-#include
+#include

Cheers,
Alex

> 
> Regards,
> Branden



-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Re: Running the grohtml pipeline as a pipeline

[G. Branden Robinson]

Hi Alex,

At 2024-03-22T20:10:51+0100, Alejandro Colomar wrote:
> Whoops!  I passed two different file names at different stages.  I
> obviously wanted to say this:
> 
>   $ preconv man3/_Generic.3 \
>   | tbl \
>   | troff -man -Thtml -wbreak \
>   | post-grohtml >g.html;

Okay.

> > Can you share an exhibit of a pipeline that fails and describe _how_
> > it fails?
> 
> Sure.  Let's add eqn(1) to that pipeline.
> 
>   $ preconv man3/_Generic.3 \
>   | tbl \
>   | eqn -Thtml \
>   | troff -man -Thtml -wbreak \
>   | post-grohtml >g_eqn.html;
>   : warning: eqn should have been given a '-Tps' 
> option(consider invoking 'groff -Thtml -e')
> 
> Hmmm, let's do what that warning says: use -Tps.
> 
>   $ preconv man3/_Generic.3 \
>   | tbl \
>   | eqn -Tps \
>   | troff -man -Thtml -wbreak \
>   | post-grohtml >g_eqnps.html;
> 
> This "works", but it results in a worse HTML file.
[...]
>   -#include
>   +#include
>stdint.h 
> 
> It reduces the base paragraph inset (did I use the right term? :) to
> almost nothing.

I have to say I regard this as a pretty minor problem compared to others
I've seen grohtml have with man pages.

However, I would also say that it's wrong that running eqn on an input
document that doesn't even _use_ eqn should change anything about the
rendering.  That's weird.

...and it turns out I can't reproduce this.

$ preconv man3/_Generic.3 | tbl | eqn -Thtml | troff -man -Thtml -Wbreak | 
post-grohtml >| _Generic-eqn-Thtml.html
$ preconv man3/_Generic.3 | tbl | eqn -Tps | troff -man -Thtml -Wbreak | 
post-grohtml >| _Generic-eqn-Tps.html
$ stat -c '%s %n' _Generic-eqn-T*
3010 _Generic-eqn-Thtml.html
3010 _Generic-eqn-Tps.html
$ diff -u _Generic-eqn-T*
--- _Generic-eqn-Thtml.html 2024-03-22 14:32:37.651496863 -0500
+++ _Generic-eqn-Tps.html   2024-03-22 14:32:24.779577657 -0500
@@ -1,5 +1,5 @@
 
-
+
 http://www.w3.org/TR/html4/loose.dtd;>
 

I can't think of anything in the last 179 commits that would have
affected this, but...179 slightly exceeds the capacity of human working
memory.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Running the grohtml pipeline as a pipeline

[Alejandro Colomar]

Hi Branden,

On Fri, Mar 22, 2024 at 01:53:51PM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2024-03-18T12:38:30+0100, Alejandro Colomar wrote:
> > I'm considering using grohtml(1) in the Linux man-pages, to replace
> > man2html(1), which crashes on tzfile(5) --which has correct man(7)--.
> 
> Well, all right.  Demand may drive improvement to grohtml more reliably
> than abandonment and neglect have.
> 
> > Currently, I'm running groff(1) as its separate constituents:
> > 
> > $ make build-ps -Wman2/membarrier.2
> > PRECONV .tmp/man/man2/membarrier.2.tbl
> > TBL .tmp/man/man2/membarrier.2.eqn
> > EQN .tmp/man/man2/membarrier.2.ps.troff
> > TROFF   .tmp/man/man2/membarrier.2.ps.set
> > GROPS   .tmp/man/man2/membarrier.2.ps
> > 
> > which runs
> > 
> > $ make build-ps -Wman2/membarrier.2 --debug=print \
> > | grep -Pv '^[[:upper:]]+\t';
> > preconv   man2/membarrier.2 >.tmp/man/man2/membarrier.2.tbl
> > tbl <.tmp/man/man2/membarrier.2.tbl >.tmp/man/man2/membarrier.2.eqn
> > ! (eqn -Tps   <.tmp/man/man2/membarrier.2.eqn 2>&1 
> > >.tmp/man/man2/membarrier.2.ps.troff) \
> > | grep ^ >&2
> > ! (troff -man -Tps -wbreak  <.tmp/man/man2/membarrier.2.ps.troff 2>&1 
> > >.tmp/man/man2/membarrier.2.ps.set) \
> > | grep ^ >&2
> > grops   <.tmp/man/man2/membarrier.2.ps.set 
> > >.tmp/man/man2/membarrier.2.ps
> > 
> > What pipeline do you recommend for HTML, using a similar pattern?
> > So far, the only thing that seems to work is
> > 
> > $ preconv man2/membarrier.2 \
> > | tbl \
> > | troff -man -Thtml -wbreak man3/_Generic.3 \

Whoops!  I passed two different file names at different stages.  I
obviously wanted to say this:

$ preconv man3/_Generic.3 \
| tbl \
| troff -man -Thtml -wbreak \
| post-grohtml >g.html;


> > | post-grohtml >g.html;
> > 
> > Although from pre-grohtml(1), maybe I shouldn't be running tbl(1)
> > myself?
> 
> grohtml uniquely runs its own output-driver-specific preprocessor, but
> more significantly, that preprocessor _runs troff_.  The main reason
> "groff -Thtml" is relatively slow is because it runs troff as part of
> running troff, scraping out chunks of PostScript and converting them to
> images.
> 
> I'm not _certain_ that what you're trying to do can't be expected to
> work.  I had suspected that tbl(1) had hooks in it for pre-grohtml(1)
> support (by testing the `ps4html` register, the usual way this is done),
> but it doesn't.
> 
> In fact, spending a few minutes looking at it, I'm not seeing anything
> that seems like it should foreclose what you're trying to do.
> 
> Can you share an exhibit of a pipeline that fails and describe _how_ it
> fails?

Sure.  Let's add eqn(1) to that pipeline.

$ preconv man3/_Generic.3 \
| tbl \
| eqn -Thtml \
| troff -man -Thtml -wbreak \
| post-grohtml >g_eqn.html;
: warning: eqn should have been given a '-Tps' 
option(consider invoking 'groff -Thtml -e')

Hmmm, let's do what that warning says: use -Tps.

$ preconv man3/_Generic.3 \
| tbl \
| eqn -Tps \
| troff -man -Thtml -wbreak \
| post-grohtml >g_eqnps.html;

This "works", but it results in a worse HTML file.

$ diff -u1 g.html g_eqnps.html 
--- g.html  2024-03-22 20:04:24.693780375 +0100
+++ g_eqnps.html2024-03-22 20:05:26.418201458 +0100
@@ -1,3 +1,3 @@
 
-
+
 _Generic 
+_Generic 
 type-generic selection
@@ -46,3 +46,3 @@
 
-_Generic(expression,
+_Generic(expression,
 type1: e1, ... /*, default: e
@@ -56,3 +56,3 @@
 
-_Generic()
+_Generic()
 evaluates the path of code under the type selector that is
@@ -63,6 +63,6 @@
 
-expression
+expression
 is not evaluated.
 
-This is
+This is
 especially useful for writing type-generic macros, that will
@@ -76,3 +76,3 @@
 
-C11.
+C11.
 
@@ -83,3 +83,3 @@
 
-C11.
+C11.
 
@@ -90,3 +90,3 @@
 
-The following
+The following
 program demonstrates how to write a replacement for the
@@ -96,3 +96,3 @@
 
-#include
+#include
 stdint.h 

It reduces the base paragraph inset (did I use the right term? :) to
almost nothing.

I have a few more cases, but let's keep it short for now.

Cheers,
Alex

> 
> Regards,
> Branden



-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Re: the Courier font family and nroff history (was: mandoc(1)'s man pages, groffed, and Project KIC)

[G. Branden Robinson]

[self-correction]

At 2024-03-22T13:24:04-0500, G. Branden Robinson wrote:
> and video terminals emulated typewriters well enough for unserious
> work like formatting man pages on a screen.

Err, this is pretty hugely false.

They didn't.

That's why you had to pipe nroff's output through col(1) or ul(1).

This fact got obscured, including from me just now, by the fact that
some pager programs took it upon themselves to interpret backslashes in
their input streams.  Probably because that's what the Teletype Model
37-oriented nroff produced for man pages, which lots of people read on
their video terminals.

My apologies for the brainfart.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Running the grohtml pipeline as a pipeline

[G. Branden Robinson]

Hi Alex,

At 2024-03-18T12:38:30+0100, Alejandro Colomar wrote:
> I'm considering using grohtml(1) in the Linux man-pages, to replace
> man2html(1), which crashes on tzfile(5) --which has correct man(7)--.

Well, all right.  Demand may drive improvement to grohtml more reliably
than abandonment and neglect have.

> Currently, I'm running groff(1) as its separate constituents:
> 
>   $ make build-ps -Wman2/membarrier.2
>   PRECONV .tmp/man/man2/membarrier.2.tbl
>   TBL .tmp/man/man2/membarrier.2.eqn
>   EQN .tmp/man/man2/membarrier.2.ps.troff
>   TROFF   .tmp/man/man2/membarrier.2.ps.set
>   GROPS   .tmp/man/man2/membarrier.2.ps
> 
> which runs
> 
>   $ make build-ps -Wman2/membarrier.2 --debug=print \
>   | grep -Pv '^[[:upper:]]+\t';
>   preconv   man2/membarrier.2 >.tmp/man/man2/membarrier.2.tbl
>   tbl <.tmp/man/man2/membarrier.2.tbl >.tmp/man/man2/membarrier.2.eqn
>   ! (eqn -Tps   <.tmp/man/man2/membarrier.2.eqn 2>&1 
> >.tmp/man/man2/membarrier.2.ps.troff) \
>   | grep ^ >&2
>   ! (troff -man -Tps -wbreak  <.tmp/man/man2/membarrier.2.ps.troff 2>&1 
> >.tmp/man/man2/membarrier.2.ps.set) \
>   | grep ^ >&2
>   grops   <.tmp/man/man2/membarrier.2.ps.set 
> >.tmp/man/man2/membarrier.2.ps
> 
> What pipeline do you recommend for HTML, using a similar pattern?
> So far, the only thing that seems to work is
> 
>   $ preconv man2/membarrier.2 \
>   | tbl \
>   | troff -man -Thtml -wbreak man3/_Generic.3 \
>   | post-grohtml >g.html;
> 
> Although from pre-grohtml(1), maybe I shouldn't be running tbl(1)
> myself?

grohtml uniquely runs its own output-driver-specific preprocessor, but
more significantly, that preprocessor _runs troff_.  The main reason
"groff -Thtml" is relatively slow is because it runs troff as part of
running troff, scraping out chunks of PostScript and converting them to
images.

I'm not _certain_ that what you're trying to do can't be expected to
work.  I had suspected that tbl(1) had hooks in it for pre-grohtml(1)
support (by testing the `ps4html` register, the usual way this is done),
but it doesn't.

In fact, spending a few minutes looking at it, I'm not seeing anything
that seems like it should foreclose what you're trying to do.

Can you share an exhibit of a pipeline that fails and describe _how_ it
fails?

Regards,
Branden


signature.asc
Description: PGP signature

Re: Milestone reached: hyperlinked mdoc(7) documents in PDF

[Alejandro Colomar]

On Fri, Mar 22, 2024 at 05:56:58PM +, Deri wrote:
> On Friday, 22 March 2024 16:59:14 GMT Alejandro Colomar wrote:
> > ow, how am I supposed to
> > get that patch without anyone tampering it during its trip to my
> > computer?  :(
> 
> derij@ws:~$ md5sum  /var/www/chinese.patch.gz 
> 109e2681b7402ca55118226aa575b6d3  /var/www/chinese.patch.gz

Hi Deri!

That matches what I downloaded back then; thanks!  :)

BTW, is that font available in any Debian package?  Maybe we can get it
from there, and add a dependency on such a package, to avoid adding the
font to the repository?  There's a 'unifont' Debian package, which I
guess is related to this, right?

Cheers,
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

the Courier font family and nroff history (was: mandoc(1)'s man pages, groffed, and Project KIC)

[G. Branden Robinson]

At 2024-03-19T18:28:13+, Lennart Jablonka wrote:
> Quoth G. Branden Robinson:
> > > And the page numbers reset at the start of each section.  Which
> > > they shouldn’t do—the book is one unit; it should get its own page
> > > numbers.  And in other books, you don’t usually see page numbers
> > > per chapter.
> > 
> > This was a bug in me, not in groff.  I forgot to specify `-rC1` when
> > generating the PDF.  Include it, and one gets 160 pages (using U.S.
> > letter paper) numbered consecutively.
> 
> How come that is not the default?

Historical inertia, most likely.  Seventh Edition Unix man(7) didn't
offer an alternative.

groff_man(7):
   History
 M. Douglas McIlroy ⟨m.douglas.mcil...@dartmouth.edu⟩ designed,
 implemented, and documented the AT man macros for Unix Version 7
 (1979) and employed them to edit the first volume of its
 Programmer’s Manual, a compilation of all man pages supplied by the
 system. ...

 ... SunOS 2.0 (1985) recognized C, D, P, and X registers.  ...

 James Clark implemented the foregoing features in early versions of
 groff. ...

> > > (“Section” being an older term for “man pages,” if memory serves
> > > right.)
> > 
> > Not as far as I know.  I use the term "document" when it's important
> > to distinguish between a coherent chunk of man(7) or mdoc(7) with
> > one `TH` or `Dd` call, respectively, and the face of a (perhaps
> > digitally) printed "leaf".
> 
> The v7 Introduction indeed calls 1, 2, … 8 “sections” and sh(1) and
> the like “entries.”  But v7 man(1) says:
> 
> > NAME
> > man - print sections of this manual
> > 
> > SYNOPSIS
> > man [ option ... ] [ chapter ] title ...
> > 
> > DESCRIPTION
> > Man locates and prints the section of this manual named
> > title in the specified chapter.  (In this context, the word

Well indeed it does.

But there is much about this 1979 man page I would quibble with, mainly
on terminological grounds.  man(7) enjoyed tremendous success and its
users strained the macro language and its semantics at every boundary.

> > ... The chapter number does not need
> > a letter suffix.  If no chapter is specified, the whole
> > manual is searched for title and all occurrences of it are
> > printed.

Alex Colomar lobbied for a resurrection of this also-vanished
terminology.  I have a bit of sympathy for that proposal, because
"section" is overloaded (differently) both in Doug's usage and modern
convention.

> > The page numbers of each entry start at 1; it is infeasible to
> > number consecutively the pages of a document like this that is
> > republished in many variant forms.
> 
> Huh.  I don’t agree.

Some historical facts to note are that back then, (1) a Unix
installation might not have had disk space for all of the man pages plus
all of the cat pages.  So some of the "on-line" man pages might have
lived only "off-line", which they (2) often did anyway--witness Holt,
Reinhart, and Winston's professionally bound and commercially sold copies
the Seventh Edition manual--but moreover, it was common practice to
maintain big binders containing Unix documentation on a bench in a lab
or terminal room.  Frequently, the leaves of man pages were n-hole
punched to permit update of "the manual" in line with the software load
of the local Unix host(s).  I trust it is obvious that a strictly
increasing numbering scheme would not long survive such updates.[1]

> Also a good point, though not what I meant.  I think Courier itself is
> an ugly type face.
[...]
> Sure, but it would be a win already to replace Courier by a different
> fixed-width type face.  But that’s site-local configuration, I guess.
> 
> It would be better still to replace Courier by a non-fixed-width type
> face, because we really don’t need to emulate the nonsense typewriters
> do in print.
[...]
> I do object to Courier in displays.  Courier is ugly.  Ugly, ugly,
> ugly.  Even under the fixed-width type faces, there are nice-looking
> ones.  Courier is not one of those.  Courier is ugly.

There is a major _technical_ problem with doing this, setting aside its
advisability.

No _standard_ PostScript or PDF font family _apart_ from Courier is
monospaced.

Plenty exist, but groff can't assume that _any_ of them are installed.
This is something you're going to have to take care of locally and
customize for the foreseeable future.  I can see about en-knobbing it
for groff man(7) and mdoc(7), of course.

At 2024-03-19T14:47:38-0500, Dave Kemper wrote:
> True if it were emulating only typewriters, but fixed-width fonts are
> still very common in terminal emulators.  So a font that emulates that
> aspect of characters to be typed at the terminal is a helpful cue to
> readers.  (Not a defense of Courier itself, but of monospace fonts in
> certain contexts.)

I happen to agree with this.  I have a mild distaste for Courier per se,
one that is probably conditioned by bad experiences long ago with
Microsoft systems where Courier 

Re: Milestone reached: hyperlinked mdoc(7) documents in PDF

[Alejandro Colomar]

Hi Branden!

On Fri, Mar 22, 2024 at 11:30:11AM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2024-03-17T23:44:07+0100, Alejandro Colomar wrote:
> > On Sun, Mar 17, 2024 at 05:23:20PM -0500, G. Branden Robinson wrote:
> > > Following up my earlier announcement regarding man(7),[1], I'm
> > > pleased to report that we have a functioning PDF hyperlink story for
> > > the mdoc package.
> [...]
> > > P.S. Alex, you might want to consider simplifying your cover page
> > >  similarly once you bring your copy of groff up to date.
> > 
> > How much would you consider having a release sooner than expected, and
> > then have what originally would have been 1.24.0 be 1.25.0?  :)
> 
> Not very much.  As I noted previously, I'm still not the official GNU
> maintainer of groff.  (This is partly procrastination and partly
> consideration for Bertrand's very tight time budget for GNU work.)

Please, please :)

> 
> > I would prefer using a packaged version of groff, for two reasons:
> > 
> > -  I got impedance mismatches, when I see stuff like the 5n base-
> >paragraph indent, but contributors are still seeing 7n.
> 
> Fair.  You _can_, of course, configure groff Git to replicate the output
> line arrangement of groff 1.23.0 and earlier, with `-rBP=7n -rLL=78n`.

I'm not a fan of configuring stuff either, because then I forget that I
did.  And I do like 5n.  I would like others to also have it, rather
than not having it myself.  :)

> > -  In my server, I have a script that builds the man-pages book for
> >every push to the main branch (true for both the Linux man-pages
> >and shadow), and another that runs the lints and checks for the
> >Linux man-pages.  Having built-from-source software in my computer
> >is less of a problem, but in a server, it's less comfortable.  (I
> >already have Deri's branch in there, and I'm not in love with
> >that.)
> 
> You're a good person to ask; is there anything from Deri's branch that
> Linux man-pages still needs?

I started using it because of the cyrillic shadow manual pages.
groff-1.23.0 has issues with them.

If you have some time for it, I'll bombard you with some questions and
requests for the Linux man-pages book-generating scripts.  :)

>  I know it has some stuff you probably
> _don't_ need, like the slanted symbol font and a new approach to
> associating glyphs in groff font description files with Unicode code
> points.
> 
> > But yeah, I'm willing to simplify as much as possible!  ;)
> 
> I won't pressure you.  If I recall correctly I still owe you another
> preliminary to the Most Disruptive Automated Change Ever Unleashed on a
> Man Page Corpus ("MR.sed"), that being something to do with man page
> cross references inside tbl(1) tables.  I'll have to review the email
> thread from January.

I don't remember what was remaining, but I think almost everything was
done.  We are missing just the final pieces, IIRC.  Still, if you manage
to simplify the sed(1) script by applying some pre-patches, it would be
easier to review.

Which reminds me of the discussion about PGP signatures on patches we
had some moons ago (something that Deri reminded me unintentionally
recently too): Deri posted a gigantic patch with a new font for
supporting the zh_CN manual pages from shadow in the PDF book.  But he
didn't sign anything, and he just posted a link to his (HTTP) web server
where his patch is hosted for me to wget(1).  Now, how am I supposed to
get that patch without anyone tampering it during its trip to my
computer?  :(

> By the time I get to it, the argument that groff 1.23 is "too new" will
> be pretty feeble...

Actually, I didn't pressure you, because that might give some time to
Ingo to add support for MR in mandoc(1).  But I didn't hear anything
from him in a long time.  But yeah, I'm ready to patch the Linux
man-pages whenever you send your next revision.

Have a lovely Spring!
Alex

> Regards,
> Branden


-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Re: Milestone reached: hyperlinked mdoc(7) documents in PDF

[G. Branden Robinson]

Hi Alex,

At 2024-03-17T23:44:07+0100, Alejandro Colomar wrote:
> On Sun, Mar 17, 2024 at 05:23:20PM -0500, G. Branden Robinson wrote:
> > Following up my earlier announcement regarding man(7),[1], I'm
> > pleased to report that we have a functioning PDF hyperlink story for
> > the mdoc package.
[...]
> > P.S. Alex, you might want to consider simplifying your cover page
> >  similarly once you bring your copy of groff up to date.
> 
> How much would you consider having a release sooner than expected, and
> then have what originally would have been 1.24.0 be 1.25.0?  :)

Not very much.  As I noted previously, I'm still not the official GNU
maintainer of groff.  (This is partly procrastination and partly
consideration for Bertrand's very tight time budget for GNU work.)

> I would prefer using a packaged version of groff, for two reasons:
> 
> -  I got impedance mismatches, when I see stuff like the 5n base-
>paragraph indent, but contributors are still seeing 7n.

Fair.  You _can_, of course, configure groff Git to replicate the output
line arrangement of groff 1.23.0 and earlier, with `-rBP=7n -rLL=78n`.

> -  In my server, I have a script that builds the man-pages book for
>every push to the main branch (true for both the Linux man-pages
>and shadow), and another that runs the lints and checks for the
>Linux man-pages.  Having built-from-source software in my computer
>is less of a problem, but in a server, it's less comfortable.  (I
>already have Deri's branch in there, and I'm not in love with
>that.)

You're a good person to ask; is there anything from Deri's branch that
Linux man-pages still needs?  I know it has some stuff you probably
_don't_ need, like the slanted symbol font and a new approach to
associating glyphs in groff font description files with Unicode code
points.

> But yeah, I'm willing to simplify as much as possible!  ;)

I won't pressure you.  If I recall correctly I still owe you another
preliminary to the Most Disruptive Automated Change Ever Unleashed on a
Man Page Corpus ("MR.sed"), that being something to do with man page
cross references inside tbl(1) tables.  I'll have to review the email
thread from January.

By the time I get to it, the argument that groff 1.23 is "too new" will
be pretty feeble...

Regards,
Branden


signature.asc
Description: PGP signature

[bug #60034] [mdoc] `Mt` macro should validate its arguments

[G. Branden Robinson]

Update of bug #60034 (group groff):

 Planned Release:None => 1.24.0 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64004] [troff] make character and glyph handling more discoverable (.pchar, ".if C", ".if G")

[G. Branden Robinson]

Update of bug #64004 (group groff):

 Summary: make character and glyph handling more discoverable
(.pchar, ".if C", ".if G") => [troff] make character and glyph handling more
discoverable (.pchar, ".if C", ".if G")


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #52463] anything that talks to standard error should identify itself

[G. Branden Robinson]

Update of bug #52463 (group groff):

  Dependency Removed: => bugs #57611


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/