Re: GNU maintainership update

[John Gardner]

Congrats, Branden!

[1] https://xkcd.com/149/


Fixed that for you:

[image: sandwich.png]




On Sat, 31 Aug 2024 at 08:26, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi folks,
>
> Bertrand and I have heard back from the GNU maintainers team.  As of
> yesterday, they have offered me the maintainer role for groff and I have
> communicated my acceptance.
>
> I haven't received notification of any changed "permission bits" or
> anything else, and don't expect to immediately, so for now I do not
> regard anything as having logistically changed; if we needed to tag and
> push groff 1.24.0.rc1 tomorrow, Bertrand would have to do it.
>
> Nevertheless we seem to be into the procedural, rather than the social,
> part of the handover process, so I thought I'd let the community know.
>
> I don't expect to update the groff web page with my changed status until
> I can "exercise maintainerly powers", as it were.[1]
>
> Regards,
> Branden
>
> [1] https://xkcd.com/149/
>
> I had a more apropos cartoon in mind, involving a ghost flying out
> of a computer monitor and a caption reading "rootly powers", that is
> at least 20 years old (a co-worker used to have it on his office
> door), but I could not find it in a web search.  Oh well.
>
> Maybe it was from Nemeth et al.'s Unix sysadmin book...
>

Unicode support for Troff-specific symbols

[John Gardner]

In Unicode 13.0, a new block
 was added
to support graphical symbols used on legacy systems,[1] particularly those
represented by obscure character encodings (like ATASCII
).[2]

I'm wondering if Troff's non-representable symbols (listed below) are
eligible additions for this block. I'm envisioning their admission to use
names like:

\[sqrtex] radical symbol extension[3]
\(ul  troff under rule
\(ru  troff baseline rule
\(bs  troff client logotype[4]

Giving these characters a canonical representation in Unicode won't benefit
documents typeset by older troff(1) implementations, but it would simplify
documentation of future Groff releases and smooth out wrinkles in text
copied from gropdf(1) output.

Does this seem realistic to anybody else? Or have I developed tunnel vision
from dwelling on this idea too much?

Regards,
— John


   1. https://www.unicode.org/L2/L2022/22016.htm#170-C15
   2. A supplementary block
   
   featuring Pac-Man and Space Invaders graphics has also been approved for
   the upcoming Unicode 16.0 (published next month). I think one of these
   "legacy computing" blocks gets the point across, however.
   3. Complements ⎷ (U+23B7  radical
   symbol bottom).
   4. I'm aware that corporate logos can't be added to the UCD (no matter
   how well-established they appear to be
   ), due to the conflict-of-interest
   regarding trademarks and brand representation. Hence why a more
   "diplomatic" name is suggested here, which relegates the exact appearance
   of \(bs to a font-level concern.

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Vincent,

I really see a "+" underlined


Is it visually distinct from an ordinary underscore? I merely ask now out
of curiosity, as Brandan explained why overstriking is a no-go.

Concerning the original problem, I find myself in agreement with the
general majority here: consistency with the existing *"+0 or -0"* language
is probably the best fallback.

Regards,
— John

On Fri, 9 Aug 2024 at 19:25, Vincent Lefevre  wrote:

> On 2024-08-09 15:53:30 +1000, John Gardner wrote:
> > Hi Vincent,
> >
> > > So ideally, the fallback for "ą0" should be "+0 or -0", which is
> > > much more readable and less ambiguous than "+-0" or "+/-0".
> >
> > For approximating ą in ASCII, is there some reason \z_+0 hasn't been
> > considered?
>
> I don't like that at all. I really see a "+" underlined, so it is
> confusing. Moreover, the information is not kept by copy-paste,
> and it is not rendered as wanted with "xterm +ulc" (to replace
> underline by color). And I don't think that it will correctly be
> interpreted by screen readers.
>
> --
> Vincent Lefčvre  - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Branden,

Numeric expressions are already valid conditional expressions, so all we'd
> need here is a syntax for interpolating an output device parameter. […] As
> it happens, `\T` is *not* yet taken.


True, but for fields that have lengthy values, it might help to have a
syntax for testing the presence (or absence) of a space-delimited token:

.ie T styles & BI \{ This device supports \f(BIbold-italic\fP text! \}
.el   \{ "BI" not listed in the DESC file's "styles" field. \}

However, I see the greater flexibility of an escape sequence that can be
utilised anywhere, not just in conditional expressions. Its output can
always be passed to a list-wrangling macro or something.

And yes, there's a story behind all those wacky `\?` things.


Wait, how long has that been supported\? (I've been away from Groff for the
past year-and-a-half, so apologies if this was a very recent addition).

And a document author, particularly of a man page, does *not* want to rely
> solely on text style changes to communicate meaning.


You're right. Hell, I believe I've made this exact same point in the past
when discussing A11Y, SEO,[1] and legible .textContent
 properties.

As a rule it's prudent to ensure that your meaning is adequately conveyed
> when the text is read aloud. That's a laudable practice in all writing.


True, but there are other, more cumbersome examples where author intent
must be communicated textually. Docopt  is probably my
favourite example of this.

Good luck. If you are ever successful I may send you a draft notice
> enlisting you in the improvement of Groff's hardcopy terminal support.


Thanks! I'm not hedging my bets, though, so in the meantime you can hit up this
guy  who somehow got an ASR-33 talking to
Linux and even Twitter's API .[2]

Email is for old men attempting to thwart all progress.


Or 37-year old hermits with ADHD who avoid instant messaging apps or social
media in favour of a digital medium most familiar to them.[3]

Also, the *real* old men who're attempting to thwart all progress are the
CEOs of Big Tech companies who keep shoving AI down our throats,
irrespective of whether we asked for it or not.[4] Because line must go up
.


(I assume that Slack and Discord clients support "rich text", and eagerly
> convert each word of styled text into 100kiB of CSS-ful HTML overhead)


Christ, I hear ya. You'd think a text-based medium like the Web would have
some efficient means of encoding textual content in a form separate from
presentational rules, in both a readable and approachable text format.
Shame that we now require Markdown processors to generate the HTML that's
piped through to the middleware that's rendered client-side in the user's
browser after loading 4.5 MBs of CDN-hosted fonts that only marginally
differ from system-installed typefaces, displayed after 10 MBs of
unoptimised Webpack chunks are loaded by the browser. I mean, what the hell
was Tim Berners-Lee thinking?

[1] Search Enshittification Operation, or the cancer that's eroded the
usefulness of search engines in recent years.
[2] Before it was ruined by Elon's BIG BRAIN™ decision to paywall the
site's API, effectively defeating its intended purpose to make Twitter
accessible to the broader web.
[3] The main advantage of the latter being that I can proof-read my
dexie-fuelled ramblings before making them public. So there's really no
excuse for this e-mail.
[4] Thank you, late-stage Capitalism, for returning us—the working class—to
serfdom. I'm sure the elites work very, very hard and aren't at all
leeching off of an inherently unsustainable system built upon exploitation
of labour.

^D

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Branden,

All of the terminal output devices groff supports lack overstriking support.


Whoops. I forgot that what I was seeing in less(1) was actually duped using
an underline effect. On that note, am I right to assume that \fI+\fP0 is
equally implausible by virtue of terminals diverging wildly in their
italicisation support? (Underlining, obliquity, ignoring the effect
outright, etc).

The enthusiastic aficionados of the Western Electric/Teletype Corporation
> Model 37, including (it would seem) many less(1) users, could then run wild
> with TERM=tty37.


That reminds me (and I'm being dead serious here), if anybody knows where a
Model 37 can be acquired in 2024, *please* let me know. (I spent all arvo
yesterday searching… seriously).

A new conditional expression operator, "T", would take a delimited argument
> naming an output device capability.


Why stop there? Such a conditional could match against a named field (and
optional value) in an output driver description (DESC) file, whether it's
recognised by Groff or not. Something like:

.if T unicode \{
.if T res > 50 \{

I mean, if we're gonna extend the syntax to include something this niche,
we may as well go all the way.

Regards,
— John



On Fri, 9 Aug 2024 at 16:19, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2024-08-09T15:53:30+1000, John Gardner wrote:
> > Hi Vincent,
>
> Not to horn in, but I think I'm better situated to venture opinions or
> background on implementation decisions taken in groff than Vincent is.
>
> > So ideally, the fallback for "±0" should be "+0 or -0", which is
> > > much more readable and less ambiguous than "+-0" or "+/-0".
> >
> > For approximating ± in ASCII, is there some reason \z_+0 hasn't been
> > considered?
>
> You anticipated the answer.
>
> > I'm asking earnestly, as I'm primed to assume overstriking hacks have
> > already been ruled out (pun intended) as a fallback.
>
> \z _is_ an overstriking hack.
>
> From groff's Texinfo manual (slightly altered):
>
>  -- Escape sequence: \o'abc...'
>  Overstrike the glyphs of characters A, B, C, ...; the glyphs are
>  centered, written, and the drawing position advanced by the widest
>  of the glyphs.
>
>  -- Escape sequence: \zc
>  Format the character C with zero width; that is, without advancing
>  the drawing position.  Use '\z' to overstrike glyphs aligned to
>  their left edges, in contrast to '\o''s centering.
>
> All of the terminal output devices groff supports lack overstriking
> support.
>
> Resolving <https://savannah.gnu.org/bugs/?63583> (waiting on me) is a
> prerequisite to doing anything about that.
>
> We would also need a new "DESC" file keyword to declare overstriking
> support in output devices, and a way to query this parameter from the
> GNU troff language.[1]  (This would also be useful for Tektronix 4014
> support.)
>
> The enthusiastic aficionados of the Western Electric/Teletype
> Corporation Model 37, including (it would seem) many less(1) users,
> could then run wild with TERM=tty37.
>
> tty37|model 37 teletype,
> OTbs, hc, os, xon,
> bel=^G, cr=\r, cub1=^H, cud1=\n, cuu1=\E7, hd=\E9, hu=\E8,
> ind=\n,
>
> I'm open to correction by Vincent or anyone else.  :)
>
> Regards,
> Branden
>
> [1] Straw man:
>
> A.  A new keyword "overstrike" or "has-overstriking" would be
> recognized by libdriver and/or libgroff.  (In practice, only
> grotty(1) would need to bother checking for it; any driver for a
> typesetter can assume that overstriking is possible.)
>
> B.  A new conditional expression operator, "T", would take a
> delimited argument naming an output device capability.
>
> So you might have something like this:
>
> .ie T'has-overstriking' .fchar \[+-] \o'_+'
> .el .fchar \[+-] +/\-
>
> The feature window for groff 1.24 is closing (maybe in a month?), though
> I still want to get #63583 landed before freezing the formatter, even
> though it's strictly just an output driver change, on the off chance
> that I _have_ to change something in the formatter to support it, and
> because Lennart Jablonka has demonstrated the patience of a saint (as
> have Deri James and TANAKA Takuji_).
>

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Vincent,

So ideally, the fallback for "±0" should be "+0 or -0", which is
> much more readable and less ambiguous than "+-0" or "+/-0".


For approximating ± in ASCII, is there some reason \z_+0 hasn't been
considered?

I'm asking earnestly, as I'm primed to assume overstriking hacks have
already been ruled out (pun intended) as a fallback.

Regards,
— John

On Fri, 9 Aug 2024 at 08:15, Dave Kemper  wrote:

> On Thu, Aug 8, 2024 at 7:59 AM Vincent Lefevre  wrote:
> > FYI, +-0 could be interpreted by the reader as in C, where a unary
> > minus operator is applied, then a unary plus operator. And about +/-0,
> > the "/" is already used a the division operator, so that this doesn't
> > help parsing.
>
> It helps *some*, in that "/" can't be a unary operator, so it signals
> to the reader that +/-0 isn't a C expression.  It also helps that
> "+/-" has been used in other contexts where ± is unavailable, so some
> readers might already be familiar with it.
>
> The latter point argues in favor of Branden's idea to change groff's
> fallback from +- to +/-.
>
> > So ideally, the fallback for "±0" should be "+0 or -0", which is
> > much more readable and less ambiguous than "+-0" or "+/-0".
>
> That is a clearer phrasing, but unfortunately, there's no way to make
> that transformation an automatic fallback in the man macros (unless
> Tadziu swoops in to prove me wrong); the whole phrase would have to be
> specifically coded that way in the individual page--something that,
> aside from being discouraged in man pages, is less reliable than one
> might hope (http://savannah.gnu.org/bugs/?65403#comment0).
>
> > Anyway, currently, for consistency, this should be "+0 or -0",
> > as this is already used:
>
> ...which luckily makes all the above moot.
>
>

Re: An exercise for the brain(-software) (bug #65474)

[John Gardner]

Well I clearly failed said exercise, because my brain has no idea what the
hell it just read.

On Thu, 4 Apr 2024 at 08:48, Bjarni Ingi Gislason 
wrote:

>   Give more people a chance to see, think and learn.
>
>   The following is from the groff bug report #65474
>
> spurious "warning: unbalanced 'el' request" when formatting zic(8)
> from TZBD project
>
>   What I forgot to write in the contribution was:
>
> Another language has polluted the code, as written.
>
> -.-.
> From comment # 3:
>
>   This is neither a spurious nor a "false positive" but a
> legitimate remark about the code.
>
>   I don't see a balance (like a two arm weight balance) with
> separate left and right loads.
>
>   The warning is falsely interpreted (translated) by humans.
>
>   The translator is not happy about how the instructions are
> written, they are not informative enough for an unambiguous
> processing.
>
>   The writer's duty is to supply the translator with all
> necessary information to make its work efficient, correct and
> without any doubt.
>
>   When humans look at the code, they add (get, have) information
> that the translator does not have.
>
> .ie \n(.g groff
> .el .ie t troff
> .el neither groff nor troff
>
>   So simply adding the needed information for a unique
> interpretation is
>
> .ie \n(.g groff
> .el \{ .ie t troff
> .el neither groff nor troff \}
>
>   which is not visible enough and not an enough structured style,
> changing to
>
> .ie \n(.g groff
> .el \{\
> .  ie t troff
> .  el neither groff nor troff
> .\}
>
> makes the "balance" visible at first glance.
>
>   In this case one can look at "groff" as being a (minimal) "code
> and style checker".
>
>   The false interpretation (translation) of warnings by humans is
> thus more common than one might suspect.
>
>   Changing the code in "groff" to eliminate such a warning is
> simply censorship and sabotage.
>
> N.B.
>
>   The showed warning "el" (code = 16) should be elevated to
> a default status.
>
> -.-.
>
> N.B.
>
>   Another exercise is bug #42675 (2014-07-03)
>
>
>

Re: The chat bots have come for groff users

[John Gardner]

>
> or because of that guy's rambling response enhanced by Boots of Striding
> and Springing?


That, and the impossibility of attempting to correct a sentence like
*"Terminals
support only four font names: R, I, B, and BI"*. Like, I know what the
user's attempting to say, but it's not so much "wrong" as it is
"incorrectable".

Terminals don't have fonts. I mean… they *do* (IBM selectric typewriters,
whaddup <https://www.youtube.com/watch?v=vNUEUth7qjc>), but not in the
sense that they're relevant to grotty(1), and… just… ugh…

Stack Exchange is dead. There is no future, only underwhelming AI gibberish
and inevitable model collapse.

On Wed, 28 Feb 2024 at 08:27, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2024-02-28T07:30:37+1100, John Gardner wrote:
> > > Terminals support only four font names: R, I, B, and BI; the
> > > *grotty*(1) man page says more. Attempting to select any other font
> > > name will fail; like much else in Unix, *roff font names are
> > > case-sensitive. *groff* 1.23.0 started issuing diagnostics upon font
> > > selection failure in many more cases than earlier versions of
> > > *groff* did
> >
> > I think I just had an aneurysm…
>
> Because of groff's more persnickety diagnostics, or because of that
> guy's rambling response enhanced by Boots of Striding and Springing? :P
>
> Regards,
> Branden
>

Re: Macro package loading best practices

[John Gardner]

0.75i -rV=13.5p -mm foobar.mm
> .H 1 Introduction
> Hello, world!
>
> $ groff -ms foobar.ms
> .nr LL 5.5i
> .nr PO 0.75i
> .nr PS 11p
> .nr VS 13.5p
> .NH 1
> Introduction
> .LP
> Hello, world!
>
> Viewed this way, mm's approach seems more flexible.
>
> I'll have to experiment with these to ensure that they work as I expect.
> If so, I reckon I'll end up with some material much like the foregoing.
>
> (I've noted with puzzlement more than once that ms has no `PL` register
> recording the page length.  Maybe adding it would make sense to support
> "continuous rendering"/infinite page length on terminals.)
>
> At 2024-02-23T22:19:18-0500, Larry Kollar wrote:
> > This is a very good point, and one I should have thought of when I
> > read Brandon’s original post last night.
> >
> > The differences between -man, -ms, and -mm are loosely analogous to
> > the XML world’s XHTML, Docbook, and DITA[1]. Nobody with the most
> > minimal understanding of either triplet are going to expect a single
> > package/transform to handle all three.
> >
> > But in the case of groff, there’s at least twice as many years of
> > inertia (compared to XML) to consider. It really does make sense that
> > an -mm based book file should invoke the macro package(s) it needs,
> > but so many of us are automatically going to put that -mm on the
> > command line (a/k/a “widespread historical expectation”). At least the
> > major packages do look to see if they’ve already been invoked before
> > running through the whole shebang again.
> >
> > In the case of those of us who have specialized[2] -ms, it would make
> > even more sense to use .mso instead of the command line “option.”
> > Our modified package could source s.tmac at the outset.
>
> I don't have a response to this, except to note that it solidly
> reinforces Dave's observations.
>
> > Now manpages… I seriously doubt we can do much about them.
>
> Probably not, as long as mandoc(1) is around to fly the banner of
> liberating man pages from *roff tyranny.  At least it does a superior
> job to its many forebears who bore that colorful standard unsteadily
> into a fiery crevasse.
>
> At 2024-02-28T07:57:07+1100, John Gardner wrote:
> > I tend to begin my documents with the following comment, designed to
> > illustrate for the author what macro packages are used by the document,
> > which preprocessors are needed, etc:
> >
> > .\" uses: -mpdfmark -man -rLL=80 tbl pic eqn
>
> Why not refer to the preprocessors by their options?  -t -p -e?
>
> FYI, there shouldn't ever be any reason to load pdfmark.tmac with either
> man page package.  Not if you're writing for portability anyway.
>
> groff man(7) (in 1.23.0) and mdoc(7) (in Git) now automatically
> hyperlink everything that they should.  I'm still working on
> anchor/bookmark autogeneration in mdoc, but I expect to land that soon
> for document/section/subsection titles.  As always, managing state
> correctly when formatting a collection of man pages is the tricky part.
> Once that's done, I expect I'll sort out the device/\X copy mode thing.
>
> > I opt for a *descriptive* directive instead of a *prescriptive* one
> > ("uses:" instead of "use:"), so folks who format my documents know
> > what options/preprocessors to use, but avoid interpreting it as a
> > literal command (which would otherwise make assumptions about the
> > author's Troff implementation and/or the availability of macro
> > packages and preprocessors).
>
> I'd say that's one of multiple legitimate approaches.
>
> Regards,
> Branden
>

Re: Macro package loading best practices

[John Gardner]

I tend to begin my documents with the following comment, designed to
illustrate for the author what macro packages are used by the document,
which preprocessors are needed, etc:

.\" uses: -mpdfmark -man -rLL=80 tbl pic eqn

I opt for a *descriptive* directive instead of a *prescriptive* one ("uses:"
instead of "use:"), so folks who format my documents know what
options/preprocessors to use, but avoid interpreting it as a literal
command (which would otherwise make assumptions about the author's Troff
implementation and/or the availability of macro packages and preprocessors).

— John



On Sat, 24 Feb 2024 at 19:04, Larry Kollar  wrote:

>
> > Dave Kemper  wrote:
> >
> > On 2/22/24, G. Branden Robinson  wrote:
> >> I've come to think that a set of "best practice" for *roff document
> >> composition is to:
> >>
> >> A.  Load your desired full-service macro package (if any) on the command
> >>line with `-m`.
> >> B.  Load any auxiliary macro packages that your document _requires_
> >>either on the command line with `-m` or at the very beginning of
> >>your document with `mso`.
> >
> > Point A is a widespread historical expectation (at least partly
> > because, far enough back in history, troff didn't have .mso), but I
> > don't think it should be generally considered best practice.
> > Command-line options ought to be what the name says: *options*.  Want
> > a different paper size or font family?  Sure, those are options.
> >
> > But in no sense is loading m.tmac optional for -mm documents.  It is
> > absolutely required, so ideally it should not be incumbent on every
> > user who wants to render that document to know which switches to flip
> > to get it to work right, but on the document author to include this
> > within the document.
>
> This is a very good point, and one I should have thought of
> when I read Brandon’s original post last night.
>
> The differences between -man, -ms, and -mm are loosely analogous
> to the XML world’s XHTML, Docbook, and DITA[1]. Nobody with
> the most minimal understanding of either triplet are going to expect
> a single package/transform to handle all three.
>
> But in the case of groff, there’s at least twice as many years of inertia
> (compared to XML) to consider. It really does make sense that an -mm
> based book file should invoke the macro package(s) it needs, but so
> many of us are automatically going to put that -mm on the command
> line (a/k/a “widespread historical expectation”). At least the major
> packages do look to see if they’ve already been invoked before running
> through the whole shebang again.
>
> In the case of those of us who have specialized[2] -ms, it would make
> even more sense to use .mso instead of the command line “option.”
> Our modified package could source s.tmac at the outset.
>
> Now manpages… I seriously doubt we can do much about them.
>
> — Larry
>
> [1] If you want to quibble about the analogy, I’ll likely agree with you.
>
> [2] DITA supports “specialization,” the defining of new elements to
> suit a particular in-house need. Whether groff or XML, the cost is in
> portability.
>
>
>

Re: The chat bots have come for groff users

[John Gardner]

>
> Terminals support only four font names: R, I, B, and BI; the *grotty*(1)
> man page says more. Attempting to select any other font name will fail;
> like much else in Unix, *roff font names are case-sensitive. *groff*
> 1.23.0 started issuing diagnostics upon font selection failure in many more
> cases than earlier versions of *groff* did


I think I just had an aneurysm…

On Tue, 27 Feb 2024 at 11:41, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> It would appear that people have started running "AI" chat bots to
> answer questions on StackExchange.
>
> The quality of response is so impressive that I'm terrified for my
> future job prospects.  :-|
>
>
> https://unix.stackexchange.com/questions/771162/grep-error-warning-cannot-select-font-i/771173#771173
>
> What do you get when you kick word salad up a level?  Concept salad?
>
> French poststructuralism?
>
> Regards,
> Branden
>

Re: Proposed: simplify `mso` request

[John Gardner]

Hi Branden,

Wouldn't this conflict with behaviour documented in groff_tmac(5)? From the
section *"Inclusion"* (emphasis mine):

GNU troff offers an improved feature in the similar request “*mso*
> *package-file-name*”, which searches the macro path for
> *package-file-name*. Because its argument is a file name, its “.tmac”
> component must be included for the file to be found; *however, as a
> convenience, if opening it fails, mso strips any such suffix and tries
> again with a “tmac.” prefix, and vice versa.*


I'm normally averse to changing documented behaviour without a compelling
motivation to do so; however, I admit that falling back on tmac.s when
s.tmac isn't found is rather unintuitive behaviour, and it doesn't strike
me as wise to mix modern Groff extensions with AT&T-era warts. So I'm
leaning tentatively in favour of this change.

— John

On Fri, 23 Feb 2024 at 07:52, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> I'd like to suggest the attached diff.
>
> What removing this code would do is make the `mso` request no longer
> look for "tmac.s" if "s.tmac" is specified as the request's argument,
> and vice versa.
>
> Here's my case against.
>
> 1.  It's needless complexity.
> 2.  The main things you'd need this for are full-service traditional
> macro package names on AT&T troff environments, where they're
> (sometimes) named "tmac.s", "tmac.an", and so forth.
> 2a. Except not all AT&T troff environments name them that way.  DWB 3.3
> troff, for instance stores them without "tmac" in the name at all.
>
> $ ls ~/dwb/lib/macros
> an
> color
> csmacros
> mmn
> mmt
> pictures
> ptx
> safe
> strings.mm
> v
> view
>
> 2b. Usually, full-service macro packages are loaded via the command line
> with the `-m` option, which is still supported, and does the
> foregoing aggressive search.
> 3.  The `mso` request itself is not portable, but a groff extension.  So
> this feature is not applicable to the use case of trying to format a
> read-only legacy *roff document with groff.
> 4.  If you wanted to hack on a legacy *roff document and use this
> feature to load a macro file from the "macro path", you could
> equivalently do this.
>
> .mso s.tmac
> .mso tmac.s
>
> 5.  But, you may point out, that will probably throw at least one
> warning, for whichever of these files isn't present on the system.
> That's harmless, but...
> 6.  As of groff 1.23.0, you can do this.
>
> .msoquiet s.tmac
> .msoquiet tmac.s
>
> ...which won't throw any diagnostics about missing files.
>
> I therefore think this code has outlived whatever utility it had.
>
> N.B., I have zero intention of killing `mso` altogether, just this weird
> feature whereupon failing to open the specified file name, it rewrites
> its argument to go looking for a _different_ file name.
>
> Comments?
>
> Regards,
> Branden
>

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[John Gardner]

>
> Are you offering to donate your labor in terms of typeface design, or will
> it be a type of deal where the community will need to collectively pitch in
> money to cover the cost of you doing it professionally?


I only meant "professional" insofar as aptitude with graphics is concerned.
I won't accept money; I'm offering my labour out of love for typography,
computer history and its preservation, and of course, the technology that
got Unix the funding it needed to revolutionise computing. In any case,
there's no actual "design" work involved: it's literally just tracing
existing shapes to recreate an existing design. I do stuff like this
<https://github.com/file-icons/icons#why-request-an-icon-cant-i-submit-a-pr>
for *fun*, for crying out loud.

Here are the few published scans I am aware of:

Nice! The more material I have, the merrier. As for the scan that Branden
and I were referring to, I've uploaded a copy to Dropbox
<https://www.dropbox.com/scl/fi/xdkq15am4zon6uosbk0m9/CSTR_54_1976.pdf?rlkey=edu8ftqj33klr6lpjcrjlpdxm&dl=0>
for you.

Cheers,
— John

On Thu, 18 Jan 2024 at 18:00, Mychaela Falconia 
wrote:

> John Gardner wrote:
>
> > I'm a professional graphic designer with access to commercial typeface
> > authoring software. Send me the highest-quality and most comprehensive
> > scans of a C/A/T-printed document, and I'll get to work.
>
> Are you offering to donate your labor in terms of typeface design, or
> will it be a type of deal where the community will need to collectively
> pitch in money to cover the cost of you doing it professionally?
>
> In either case, the "C/A/T-printed document" of most value to this
> project would be the same one G. Branden Robinson is referring to:
>
> > If you don't have my scan of CSTR #54 (1976), which helpfully dumps all
> > of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me
> > know and I'll send it along.  I won't vouch for its high quality but it
> > should be comprehensive with respect to coverage.
>
> The paper in question is Nroff/Troff User's Manual by Joseph F. Ossanna,
> dated 1976-10-11, which was indeed also CSTR #54.  The document is 33
> pages long in its original form, and page 31 out of the 33 is the most
> interesting one for the purpose of font recreation: it is the page that
> exhibits all 4 fonts of 102 characters each.  Here are the few published
> scans I am aware of:
>
> 1) Page 245 of:
>
>
> http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_January_1979_Volume_2A_SRI_Reprint_June_1980.pdf
>
> 2) Page 235 of:
>
>
> http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seventh_Edition_Vol_2_1983.pdf
>
> 3) Page 239 of:
>
>
> http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manual_Edition_Seven_Volume_2A_197901.pdf
>
> 4) Page 499 of:
>
> https://archive.org/details/uum-supplement-4.2bsd
>
> Question to Branden: the scan you are referring to as "my scan", how
> does it compare to the 4 I just linked above?  If your scan has better
> quality than all 4 versions I linked above, can you please make it
> public?
>
> M~
>

Re: Proposed: make \X read its argument in copy mode

[John Gardner]

>
> This assumes you know both the desired font and the desired colour, which
> might be defined at other places in the document and not under your control.


Yeah, I know. I was trying to gauge how Groff's escape sequences might
benefit an \X'…'  sequence, and the PostScript I gave was a
contrived—albeit functional—example of interpolating the current font-size.

(Also, PostScript and grops(1) expect to work in two very different
coordinate systems, as the former's origin starts in the bottom-left corner
of the page).

On Thu, 18 Jan 2024 at 04:26, Tadziu Hoffmann 
wrote:

>
> > > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP
>
> > \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont
> setfont (Text) show'
>
> This assumes you know both the desired font and the desired
> color, which might be defined at other places in the document
> and not under your control.  Thus, unless you need multiple
> colors/fonts/sizes within the device code, it is probably more
> practical to set theses outside, as in Branden's original sketch.
>
> Here is a possibly useful example:
>
>   .defcolor my-outline-color rgb 0.9 0 0.7
>   .fp 4 BI LinLibertineOBI
>   .\" 
>   .de outline
>   \Z'\N'32''\X'ps: exec \\n(.s 0.01 mul setlinewidth (\\$1) true charpath
> stroke'\h'\w'\\$1'u'
>   ..
>   .\" 
>   Here is some
>   .gcolor my-outline-color
>   .ft BI
>   .outline outlined\/
>   .gcolor
>   .ft
>   text.
>
> (Note that this code is not optimal, in particular because
> grops does not set the font unless it is outputting something,
> necessitating the hack of printing an explicit space with
> \N'32' in order to get grops to set the desired font.)
>
>
>

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[John Gardner]

> https://usenet.trashworldnews.com/?thread=614089 posted February 1988
> Perl Kit, Version 1.0, Copyright (c) 1987, Larry Wall

Excuse my Roff,[1] but holy f\*(&#g shit. Is this where it all started? Did
one of my favourite programming languages begin with this very newsgroup
post? D—amn. Thanks for sharing!


> You might consider, as an initial step, just not bothering with stdio.

You're right, actually. System calls should be enough. I'm too used to
relying on C's standard library, heh.


> Much of my programming career has been a repeated series of lessons in
> decomposing problems into almost ridiculously small components.

 You'd love PostScript then, because once you grok it, it feels like
learning to code for the first time all over again. It forces you to
approach problem-solving and programming differently, because the solutions
you're normally used to writing in C-based languages are often dead weight
in PostScript.

I'd love to babble about PostScript further, but I've already derailed this
thread far enough, so… end of diatribe.

[1] .ds &# uckin

On Thu, 18 Jan 2024 at 03:25, Rich Salz  wrote:

> https://usenet.trashworldnews.com/?thread=614089 posted February 1988
>
> Perl Kit, Version 1.0, Copyright (c) 1987, Larry Wall
>
>
>

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[John Gardner]

>
> If you don't have my scan of CSTR #54 (1976) […] let me know and I'll send
> it along.

I have a copy named CSTR_54_1976.pdf with a SHA256 checksum of
71d8592991635966cc86a184d7a5b07163298a53c2a900fa0e9bf1a3eabeeb7d. Is this
it?

It's decent-enough quality, but I wanted to check to make sure there wasn't
a higher-resolution copy I could be working off. So, no complaints. How
urgently are the C/A/T typefaces needed?

Too bad Unix V7 didn't have Perl, since this is basically a text
> transformation problem.

It *does* have awk(1) and sed(1), IIRC, which I can get by with for most
text-wrangling tasks. :)

Let me know in private mail where you got stuck.  Maybe I can help.

I'll probably need you to review any shims I write for any C89+ stdio(3)
functions that don't exist in V7's C compiler (which is surprisingly
limited)…

Thanks!
— John



On Thu, 18 Jan 2024 at 01:08, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2024-01-18T00:43:41+1100, John Gardner wrote:
> > I'm a professional graphic designer with access to commercial typeface
> > authoring software. Send me the highest-quality and most comprehensive
> > scans of a C/A/T-printed document, and I'll get to work.
>
> If you don't have my scan of CSTR #54 (1976), which helpfully dumps all
> of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me
> know and I'll send it along.  I won't vouch for its high quality but it
> should be comprehensive with respect to coverage.
>
> > Thanks for reminding me, Branden. :) I've yet to get V7 Unix working
> > with the latest release of SimH,
>
> Let me know in private mail where you got stuck.  Maybe I can help.
>
> > I'm still up for this, assuming you've not already started.
>
> No, I haven't--perhaps because I am an Ada fanboy, the prospect of
> coding in pre-standard C and its mission to turn anything that can be
> lexically analyzed into _some_ sequence of machine instructions has not
> stoked my excitement.
>
> (Which isn't to say that one _can't_ write safe code using K&R C; my
> fear is that having to remember all of the things the compiler won't do
> for you would overwhelm the task at hand.  Too bad Unix V7 didn't have
> Perl, since this is basically a text transformation problem.)
>
> Regards,
> Branden
>

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[John Gardner]

Hi Mychaela,

*My feeling is that the task would require hiring a professional typeface
> designer*

I'm a professional graphic designer with access to commercial typeface
authoring software. Send me the highest-quality and most comprehensive
scans of a C/A/T-printed document, and I'll get to work.

*John Gardner wrote yet another [cat2dit] but it's in JavaScript so not
> maximally convenient for a Unix command line grognard.*

Thanks for reminding me, Branden. :) I've yet to get V7 Unix working with
the latest release of SimH, so that's kind of stalled my ability to develop
something in K&R-friendly  C.

I'm still up for this, assuming you've not already started. The JavaScript
utility was just a Q&D script added to an already rushed project (Roff.js),
and I"m certainly not counting on it being palatable to anybody.

— John


On Tue, 9 Jan 2024 at 00:08, Mychaela Falconia 
wrote:

> G. Branden Robinson  wrote:
>
> > This sort of broad, nonspecific, reflexive derogation of groff (or GNU
> > generally) is unproductive and frequently indicative of ignorance.
>
> I don't have enough spoons to engage in political fights any more, so
> I'll just focus on technical aspects.
>
> > The C/A/T's fonts did not even exist in the digital domain.  They were
> > produced from photographic plates.  Their reproduction is consequently
> > something of a pickle.
>
> I am very keenly aware of this fact!
>
> > But if you are going for pixel-perfect reproduction of documents that
> > used fonts you don't have, you're going to need to recreate the fonts
> > somehow--perfectly (at least for the glyphs that a given document uses).
>
> The problem you are describing is one which I am *not* actively working
> on presently.  I am _contemplating_ this problem, but not actively
> working on it.  In my current stage of 4.3BSD document set reprinting,
> I am willing to accept that hyphenations, line breaks and page breaks
> will be different from the original because of slightly different font
> metrics, and accept the use of only fi and fl ligatures (in running
> text, outside of explicit demonstrations) because Adobe's version
> dropped ff, ffi and ffl.  (In places where original troff docs
> explicitly demonstrate the use of all 5 ligatures, I have a hack that
> pulls the missing ligs from a different, not-really-matching font.)
>
> I am willing to accept this imperfection because it is fundamentally
> no different from what UCB/Usenix themselves did in 1986: they took
> Bell Labs docs that were originally written for CAT and troffed them
> on their APS-5 ditroff setup - but those two typesetters also had
> slight diffs in their font metrics, causing line and page breaks to
> move around!
>
> OTOH I am very willing to entertain, as an intellectual exercise, what
> would it take to produce a new font set that would *truly* replicate
> the CAT font set at Bell Labs.  The spacing widths of the original
> fonts (the key determinant of where breaks will land) are known, right
> here:
>
> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/tab3.c
>
> Back in 2004 in one afternoon I threw together a quick-hack program
> that takes the output of original troff (CAT binary codes) and prints
> it in PostScript, using standard Adobe fonts.  The character
> positioning is that of original troff, but because the actual font
> characters don't perfectly match these metrics, the result is not
> pretty - but the non-pretty result does show *exactly* where every
> line and page break lands per original intent!
>
> So what would it take to do such a re-creation properly?  My feeling
> is that the task would require hiring a professional typeface designer
> to produce a modified version of Times font family: modify the fonts
> to produce good visual results (change actual characters as needed) to
> fit the prescribed, unchangeable metrics as in spacing widths.  And
> design all 5 f-ligatures while at it.
>
> I have no slightest idea how much it would cost to hire a professional
> typeface designer to do what I just described, hence I have no idea
> whether or not it is something that the hobbyist community could
> potentially afford, even collectively.  But it is an interesting idea
> to ponder nonetheless - which is where I leave it for now.
>
> > There is a third problem, whose resolution is in progress, when
> > producing PDF output from this document; slanted Greek symbols are
> > present but "not quite right".  This is because unlike PostScript, PDF
> > font repertoires generally don't provide a "slanted symbol" face.
>
> Can you please elaborate?  I personally hate PDF with a p

Re: Proposed: make \X read its argument in copy mode

[John Gardner]

Hi Branden,

So instead of:
> \X'ps: \fB\s(12\m[red]big bold red text in my device command\fP'
>
> one would write:
> \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP


I believe you meant to provide an example more like this?

\X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont
setfont (Text) show'

Regards,
— John


On Wed, 17 Jan 2024 at 06:23, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Or: Should device control commands affect the environment?
>
> Recall the definition of the \X escape sequence from CSTR #54 (1992).
>
>   10.7.  Transparent output.  The sequence \X'anything' copies anything
>   to the output, as a device control function of the form x X anything
>   (§22).  Escape sequences in anything are processed.
>
> The foregoing doesn't say anything about copy mode.  This has a
> brow-raising consequence.
>
> Consider the following input.
>
> $ cat backslash-X-affects-environment.roff
> .sp
> .tm .f=\n(.f
> \X'\fB'
> .tm .f=\n(.f
>
> Documenter's Workbench 3.3 troff, Heirloom Doctools troff, and GNU troff
> all produce the same output to the standard error stream.
>
> .f=1
> .f=3
>
> What they produce as device-independent output might be even more
> interesting.
>
> $ DWBHOME=. ./bin/troff backslash-X-affects-environment.roff \
>   | grep '^x X'
> .f=1
> .f=3
> x X
>
> $ ./bin/troff backslash-X-affects-environment.roff | grep '^x X'
> .f=1
> .f=3
> x X LC_CTYPE en_US.UTF-8
> x X
>
> $ ~/groff-stable/bin/groff -Z ./backslash-X-affects-environment.roff \
>   | grep '^x X'
> .f=1
> .f=3
> x X
>
> Nothing.
>
> So "anything" doesn't exactly make it to the output as a device control,
> "transparently" or otherwise.  This is because a handful of escape
> sequences, like \f, \s, and the GNU extensions \m and \M (which set the
> stroke and fill colors, respectively) are never turned into nodes by the
> tokenization process; instead, (when not in copy mode) they immediately
> alter the current environment.
>
> Another thing to know is that there is no such thing as an environment
> in troff's output language.  Changes to the environment manifest as one
> or more other output commands, like 'f' for font selection, or 's' to
> set the type size.
>
> This foregoing exhibits seem like evidence of a design wart to me.  On
> no *roff do such escape sequences survive to device independent output;
> they can't, because they have no (direct) representation there.
>
> I therefore propose to change this, and have the `\X` escape sequence
> read its argument in copy mode.  That will make it work like the
> `device` request in groff 1.23.0 and earlier[1].
>
> Some things this wouldn't change:
>
> 1.  The ability to interpolate registers and strings inside device
> control commands--which I would guess is the main reason "Escape
> sequences in anything are processed" as CSTR #54 puts it--remains.
>
> 2.  The ability to affect the environment "simultaneously" with a device
> control command remains possible; just put those escape sequences
> _outside_ the device control escape sequence.
>
>So instead of:
>
>\X'ps: \fB\s(12\m[red]big bold red text in my device command\fP'
>
>one would write:
>
>\fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP
>
>...though I am dubious that the former has ever been well-defined
>as far as interactions with device operations go.
>
> Thoughts?  Objections?  Counterexamples?
>
> Regards,
> Branden
>
> [1] Earlier this week I pushed a change to make `device` read _its_
> argument in interpretation, not copy, mode.  My second thoughts
> about that are what prompted this proposal.
>
> See  for background.
>

Re: missing -Tpdf (and the curious case of mandoc_roff(7))

[John Gardner]

>
> I wonder why mandoc didn't just call its roff(7) page mandoc(7), given
> that it parallels groff(7) more than anything else.
>

Strictly speaking, Groff is at fault here; the manual page dedicated to the
Roff language proper should have been named as such, whereas groff(1)
pertains to an executable.

So, mandoc's naming is correct nomenclature, IMHO.

On Sun, 30 Jul 2023 at 06:37, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Doug,
>
> At 2023-07-29T15:16:42-0400, Douglas McIlroy wrote:
> > Cygwin did exclude gropdf and pdfgroff. "The accompanying man page"
> > that I meant was groff.1. Perhaps that man page should say that not
> > all groff distributions support pdf.
>
> Okay.  I want to keep groff(1)'s comprehensive list of man pages, and
> not generate variants of it at build time depending on configuration
> options.  But a note as you suggest is going to be more reliable than
> trusting distributors to patch the man pages to reflect their own
> configurations.
>
> Off the top of my head, configuration options affect the availability
> of gropdf(1), grohtml(1), gxditview(1), and xtotroff(1).
>
> Not precisely related, but to get it on record on the groff mailing
> list, I've noticed while observing 1.23.0 uptake that some distributors
> discard groff's soelim(1) and roff(7) man pages in favor of mandoc's.
> That's a shame.  The loss of the latter is a particularly sore point
> given all the content it has.
>
> I wonder why mandoc didn't just call its roff(7) page mandoc(7), given
> that it parallels groff(7) more than anything else.
>
> Regards,
> Branden
>

Re: missing -Tpdf (and the curious case of mandoc_roff(7))

[John Gardner]

>
> Eh?  That's precisely what it is.  It covers matters that are (more or
> less) common to all roff implementations.  Have you looked at it?


Sorry, my wires got crossed. I completely misread this discussion…

I'll see myself out.



On Sun, 30 Jul 2023 at 09:42, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2023-07-30T09:35:28+1000, John Gardner wrote:
> [I wrote:]
> > > I wonder why mandoc didn't just call its roff(7) page mandoc(7), given
> > > that it parallels groff(7) more than anything else.
> >
> > Strictly speaking, Groff is at fault here; the manual page dedicated
> > to the Roff language proper should have been named as such,
>
> Eh?  That's precisely what it is.  It covers matters that are (more or
> less) common to all roff implementations.  Have you looked at it?
>
> roff(7) Miscellaneous Information Manual roff(7)
>
> Name
> roff - concepts and history of roff typesetting
>
> Description
> The term roff denotes a family of document formatting systems known
> by names like troff, nroff, and ditroff.  A roff system consists of
> an interpreter for an extensible text formatting language and a set
> of programs for preparing output for various devices and file
> formats.  Unix‐like operating systems often distribute a roff
> system.  The manual pages on Unix systems (“man pages”) and
> bestselling books on software engineering, including Brian Kernighan
> and Dennis Ritchie’s The C Programming Language and W. Richard
> Stevens’s Advanced Programming in the Unix Environment have been
> written using roff systems.  GNU roff—groff—is arguably the most
> widespread roff implementation.
>
> Below we present typographical concepts that form the background of
> all roff implementations, narrate the development history of some
> roff systems, detail the command pipeline managed by groff(1),
> survey the formatting language, suggest tips for editing roff input,
> and recommend further reading materials.
>
> [...800+ more lines of text follow...]
>
> > whereas groff(1) pertains to an executable.
>
> Yes.  And groff(7) describes the language interpreted by GNU troff(1).
>
> groff_diff(1) covers the differences from CSTR #54.
>
> > So, mandoc's naming is correct nomenclature, IMHO.
>
> If you want to argue that only an equivalent to CSTR #54 deserves the
> roff(7) page, then mandoc(1) doesn't get that any more right than we do.
> And it likely won't, because so many roff language features are beyond
> the scope of that project's mission.
>
> Regards,
> Branden
>

Re: a morsel of groff 1.23.0 status

[John Gardner]

Bravo to everybody involved!!

Seriously, I can't express just how good it feels to see a long-awaited
release finally be published to the world. :)

On Thu, 6 July 2023, 8:12 am G. Branden Robinson, <
g.branden.robin...@gmail.com> wrote:

> At 2023-07-05T23:31:54+0200, Bertrand Garrigues wrote:
> > I've pushed tag 1.23.0 and published the archive on
> > https://ftp.gnu.org/gnu/groff/
>
> Rock and roll, and good times!
>
> > For the announcement email I'll send the mail to info-...@gnu.org as you
> > don't have the official maintainer title yet.
>
> Ah!  If I had known it was sender-restricted, I'd forgotten.
>
> > There are some guidelines
> > to follow [1], basically a short presentation, then were to get the
> > soft, then the NEWS file.
>
> I see--I hadn't actually read that section before.  I do note that it
> says only what should be included, and doesn't discourage us from saying
> more, which my announcement template admittedly does.
>
> > You can see my previous announcement here [2], I intend to write
> > something similar and mentioning you as the lead developer.  Do you
> > see any important things to add?
>
> If what I'm using as a template in the ANNOUNCE file[A] doesn't fit what
> you want to say, then I'd suggest adding the following, though I don't
> insist on either of them.
>
> 1.  Use the description of groff that is now synchronized between our
> home page, Texinfo manual, and man pages.
>
> ---
> groff (GNU roff) is a typesetting system that reads plain text
> input files that include formatting commands to produce output in
> PostScript, PDF, HTML, or DVI formats or for display to a terminal.
> Formatting commands can be low-level typesetting primitives, macros
> from a supplied package, or user-defined macros. All three
> approaches can be combined.
>
> A reimplementation and extension of the typesetter from AT&T Unix,
> groff is present on most POSIX systems owing to its long association
> with Unix manuals (including man pages). It and its predecessor are
> notable for their production of several best-selling software
> engineering texts.  groff is capable of producing typographically
> sophisticated documents while consuming minimal system resources.
> ---
>
> 2.  Incorporate the "Changes" section from the "ANNOUNCE" file.  I think
> it useful for at least two reasons: it summarizes the gigantic
> amount (nearly 700 lines) of "NEWS" for this release; it underscores
> the emphasis on quality of implementation.  May I be excused some
> pride in our delivery of over 400 bug fixes and 150 automated tests?
>
> I do grant that if you include both of the above, a modification of
> your 1.22.4 release announcement will look more like than unlike the
> "ANNOUNCE" template.
>
> The writing of promotional copy is not my strong suit, but my concern
> here is to ensure that users of groff 1.22.4 are not lacking reasons to
> upgrade, so I think it is worth going to a little trouble to flog
> 1.23.0's advantages: not just more features, but more testing, more
> documentation, and a better quality of life for our community.
>
> (On that high note, I should probably go re-watch _Glengarry Glen Ross_
> to remind myself what salesmen are really like...)
>
> Above all, _thank you_ for being the groff maintainer and working to
> make this release possible!  Let me know what sort of fermented or
> distilled beverage you enjoy.  :)
>
> > [1] https://www.gnu.org/prep/maintain/html_node/Announcements.html
> > [2] https://lists.gnu.org/archive/html/info-gnu/2018-12/msg00015.html
>
> Best regards,
> Branden
>
> [A]
> https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=198346d187de9e340bbf9d4f80c2dc4d42f5f74e
>

Re: notice: intent to diganose use of 'Df'

[John Gardner]

Hi Branden,

If you review the attached diff, it does in fact retain support for the
> feature, it's simply noisy about it.
>

I did review it, but those aren't the changes that worry me. Rather, it's
the ones they appear to allude to: "support for `\D'f…' *may* (or may not)
disappear in the next release".

 Do you also object to the emission of these diagnostic messages?


Not at all, but the undercurrent of urgency is a tad misleading.
Personally, I'd replace *"may disappear in the next release"* with *"may
disappear in a future release"* so it sounds less like an imminent or
planned removal.

Apart from that, I wholeheartedly endorse making deprecation warnings more
obvious and noticeable by users.

On Thu, 29 Jun 2023 at 21:39, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-06-29T19:45:18+1000, John Gardner wrote:
> > Support for 'f' may disappear in the next release, producing an error
> > > diagnostic regarding an unrecognized command.
> > >
> >
> > This doesn't sit right with me. Removing an obsolete feature to
> > encourage adoption of a newer one runs counter to Groff's normative
> > handling of legacy features—a manual that's formatted correctly and
> > consistently for the past 20 years will logically be expected to
> > continue doing so. I'm aware that \D'f…' isn't supported by AT&T Troff
> > (although it *is* supported by SQTroff), but that strikes me as a weak
> > argument to justify the feature's removal.
> >
> > Assuming there's no practical benefit to removing \D'f…' outright, I
> > instead suggest documenting it as an explicitly obsolete feature,
> > similar to how the *"Legacy command(s)"* section in groff_out(5)
> > documents the old "jump right *dd*u and print char *c**"* method for
> > outputting text. The section makes it crystal clear to readers that
> > this syntax is supported for backwards compatibility only, and
> > suggests modern alternatives they should be using instead. \D'f…'
> > should do likewise, IMO.
>
> I should have titled the thread "further deprecate" or "diagnose on use
> of".  So I am doing so now.
>
> If you review the attached diff, it does in fact retain support for the
> feature, it's simply noisy about it.
>
> diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
> index e86644da5..2067f0a19 100644
> --- a/src/devices/gropdf/gropdf.pl
> +++ b/src/devices/gropdf/gropdf.pl
> @@ -3140,6 +3140,7 @@ sub do_D
>  }
>  elsif ($Dcmd eq 'f')
>  {
> +   Warn("'f' drawing command is obsolete; use 'Fg' instead");
> my $mcmd=substr($par,0,1);
>
> $par=substr($par,1);
> diff --git a/src/libs/libdriver/input.cpp b/src/libs/libdriver/input.cpp
> index 821b526bd..78f73379a 100644
> --- a/src/libs/libdriver/input.cpp
> +++ b/src/libs/libdriver/input.cpp
> @@ -1361,6 +1361,7 @@ parse_D_command()
>  }
>case 'f':// Df: set fill gray; obsoleted by DFg
>  {
> +  warning("'f' drawing command is obsolete; use 'Fg' instead");
>IntArg arg = get_integer_arg();
>if ((arg >= 0) && (arg <= 1000)) {
> // convert arg and treat it like DFg
> diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
> index e797e2200..cc0b59f38 100644
> --- a/src/roff/troff/input.cpp
> +++ b/src/roff/troff/input.cpp
> @@ -8754,6 +8754,9 @@ static node *read_draw_node()
> error("even number of arguments needed for spline");
>   break;
> case 'f':
> + error("'f' drawing command is obsolete;"
> +   " use 'Fg' drawing command, 'M' escape sequence,"
> +   " or 'fcolor' request instead");
>   if (npoints != 1 || !no_last_v) {
> error("one argument needed for gray shade");
> npoints = 1;
>
> Do you also object to the emission of these diagnostic messages?
>
> The actual feature removal is something I don't contemplate for groff
> 1.24, may never happen (though I think we should not pretend to
> foreclose the option from future groff developers, which means warning
> users strongly now/soon), and would prefer to discuss your philosophy of
> feature retention in a separate thread.
>
> Regards,
> Branden
>

Re: notice: intent to kill off 'Df'

[John Gardner]

Hi Branden,

Support for 'f' may disappear in the next release, producing an error
> diagnostic regarding an unrecognized command.
>

This doesn't sit right with me. Removing an obsolete feature to encourage
adoption of a newer one runs counter to Groff's normative handling of
legacy features—a manual that's formatted correctly and consistently for
the past 20 years will logically be expected to continue doing so. I'm
aware that \D'f…' isn't supported by AT&T Troff (although it *is* supported
by SQTroff), but that strikes me as a weak argument to justify the
feature's removal.

Assuming there's no practical benefit to removing \D'f…' outright, I
instead suggest documenting it as an explicitly obsolete feature, similar
to how the *"Legacy command(s)"* section in groff_out(5) documents the old
"jump right *dd*u and print char *c**"* method for outputting text. The
section makes it crystal clear to readers that this syntax is supported for
backwards compatibility only, and suggests modern alternatives they should
be using instead. \D'f…' should do likewise, IMO.

Regards,
— John

On Thu, 29 Jun 2023 at 04:13, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> I admit this may be a bit rash with only 20 years of warning.
>
> If anyone's wondering, the 'Df' drawing command is not documented in
> CSTR #54.
>
> Also see .
>
> This if for groff 1.24--but to give more notice, if there is to be a
> groff 1.23.1, I propose cherry-picking it onto a 1.23-stable branch or
> similar.
>
> Diff attached.  Comments welcome.
>
> troff
> -
>
> o GNU troff now issues an error diagnostic when the 'f' drawing command
>   is used (in a `\D'f 500'` escape sequence, for example).  This drawing
>   command was declared obsolete in this NEWS file 20 years ago as part
>   of the groff 1.19 release.  Users of this escape sequence will want to
>   migrate to the `Fg` drawing command or use higher level language
>   features, like the `defcolor` and `fcolor` requests, and the `\M`
>   escape sequence, for setting a grayscale fill color for geometric
>   objects.  Support for 'f' may disappear in the next release.
>
> Output drivers
> --
>
> o Output drivers now issue a warning diagnostic when the 'f' drawing
>   command is used (`Df 500 0`, for example).  This drawing
>   command was declared obsolete in this NEWS file 20 years ago as part
>   of the groff 1.19 release.  Users of this escape sequence will want to
>   migrate to the `Fg` drawing command to set a grayscale fill color for
>   geometric objects.  Support for 'f' may disappear in the next release,
>   producing an error diagnostic regarding an unrecognized command.
>
> Regards,
> Branden
>

Re: Mission statement and Knuth-Plass reconsidered

[John Gardner]

Hi Deri,

I understand the main problem with type 1 fonts is the 256 glyph
> restriction with pdfs, there is no such restriction in the font itself, I
> have Japanese type 1 fonts with more than 18000 glyphs which can be used in
> pdfs. Type 1 is dumber than more modern formats, but the glyphs themselves
> are the result of stroked  paths, just the same, it means that the
> intelligence has to be in the software rather than the font itself.
> Attached is the Japanese version of the groff.7 man page produced by groff.
>

No, I wasn't referring to Groff's PDF/font handling, but rather, that of
the software that generated and/or processed tb69thanh.pdf (which clearly
wasn't Troff-generated). (I'm aware that custom encoding vectors can
alleviate the headaches involved with subsetting large typefaces).

(Apologies for the semi-tangent)
— J

On Wed, 24 May 2023 at 09:57, Deri  wrote:

> On Tuesday, 23 May 2023 23:49:05 BST John Gardner wrote:
> > The embedded typeface (both in the original PDF and Deri's version) are
> > encoded in Type 1 format. Given the constraints of that particular font
> > format, it wouldn't surprise me if the conversion from TeX's font-format
> > (whatever the hell it is) was a crude one. Type 1 font files are also
> > limited to 255 characters, so robust character sets need to be stored in
> > multiple separate "fonts" (which would explain the hideous kerning of
> > "Žena" and "Můj").
>
> I don't think either version is original. The first file had been
> processed by
> ghostscript and we know that the original was produced on pdftex so
> ghostscript would not be in the workflow. The second was produced by
> pdftex-0.14h which is roughly contemporaneous with the thesis, but it also
> records that it was modified 3 years ago, and it claims to be pdf 1.6,
> which
> was not around in 2001.
>
> I understand the main problem with type 1 fonts is the 256 glyph
> restriction
> with pdfs, there is no such restriction in the font itself, I have
> Japanese
> type 1 fonts with more than 18000 glyphs which can be used in pdfs. Type 1
> is
> dumber than more modern formats, but the glyphs themselves are the result
> of
> stroked  paths, just the same, it means that the intelligence has to be in
> the
> software rather than the font itself. Attached is the Japanese version of
> the
> groff.7 man page produced by groff.
>
> The weird Můj is because in the pdf it strokes "Brno - M" followed by the
> ring
> glyph after which it jumps back and draws the "u". The problem is that it
> jumps back a little too far, so this is an error in the computation of the
> distance to jump backwards, rather than using a type 1 font.
>
> Cheers
>
> Deri
>
>
>

Re: A new ignoramus question about user-installed fonts

[John Gardner]

Hi Oliver,


> message by GhostScript: Can't embed the complete font DFSongStd as it is
> too large, embedding a subset
>

PostScript provides a dedicated resource-type for exactly this: a CID-keyed
font (PLRM § 5.11
).
The specifics of it are beyond this discussion, but it stands to reason
that a CID-font should be used for subsetting a CJK font. This might be
beyond gropdf(1)'s current capabilities, though.


> монгол үлгэр.


Now do *real* Mongolian[1]

$ groff > /tmp/timur.pdf -Tpdf < ᠮᠣᠩᠭᠣᠯ ᠪᠢᠴᠢᠭ
>
EOF


On Sun, 23 Apr 2023 at 07:28, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Oliver,
>
> At 2023-04-21T20:13:14+0200, Oliver Corff wrote:
> > thank you very much for your encouraging feedback.
>
> I try to moonlight occasionally from my normal gig of gripes and
> laments.  ;-)
>
> > Indeed I did neither mention nor note in the example file (multitest.ms
> > --- I thought the .ms in the file name tells the story)
>
> I managed to overlook your input file name in your original mail.
> Perhaps the pale green contact lenses obscured my vision...
>
> > that I use groff_ms(7) as it is really at a sweet spot between
> > simplicity of use and aesthetics of produced document.
>
> I also think it delivers a lot of value from a fairly simple interface.
>
> We've complicated it a bit lately with an eye toward better PDF
> support, but if I can get a new feature or two into the formatter, I
> think we'll be able to take a couple of those extensions back out and do
> things "magically".
>
> https://savannah.gnu.org/bugs/?62264
> https://savannah.gnu.org/bugs/?62787
> https://savannah.gnu.org/bugs/?63074
>
> If I'm _really_ lucky (and correct about GNU troff's internal design),
> then implementing the ideas above will permit the removal of the
> `asciify` and `unformat` requests from the formatter as well.  (We would
> of course keep them around as macros someplace for backward
> compatibility.)
>
> > I remember I had used the .fam request before, at the very beginning
> > of a document, which always produced the desired result: the *entire*
> > document is typeset in the selected family.
>
> It's not too unusual to use a different font family for headers and
> footers.  (I haven't ever seen a different face used for
> _footnotes_--just a change to a smaller type size--but since those are
> maintained in a separate environment in ms(7), it was easy enough to
> support such a distinction.)
>
> The driver behind the groff 1.23.0 change, which makes the FAM string
> more flexible, can be found in .
>
> Long story short, one of Deri's documents brought a feature gap to my
> attention!
>
> > However, since this time I used .fam for the first time somewhere
> > within the document, I first failed to understand that, in this case,
> > its scope is limited to the current paragraph. This is a tentative
> > statement from my side, I should really test which of the .LP, .PP,
> > .SH, .NH etc.  requests will end the effect of the .fam request.
>
> All of them (indirectly) call the internal macro `par@reset` (via
> `par*start` or `par*finish`), so all of them will, I think.  Again, I
> suggest using the FAM string instead, except for small-scale typographic
> stunts.
>
> --snip--
> Like,
> we're gonna have most of this sentence set in Times,
> .fam P
> but switch to Palatino right here because we're wack like that.
> .fam
> .
> And then go back and pretend like nothing happened.
> --end snip--
>
> You will note that the `\F` escape sequence could have been used just as
> well to achieve the above.  It's never been incorrect to break through
> the floor to the formatter in ms(7)--but doing so requires the user to
> understand the formatter and, perhaps, internals of the macro package.
> That would fly in the Murray Hill CSRC but not with the Unix Support
> Group.  Lesk didn't quite rouse himself to prohibiting _anything_.  The
> mm(7) and me(7) manuals were a bit more strident about refusing to
> support the arbitrary use of formatter features.
>
> > After reading your mail, I tried again to start the whole document with
> > the .fam Libertine request, et voilà, the whole document is typeset in
> > the chosen font family.
>
> I'm glad it worked out!  I do think
>
> .ds FAM Libertine
>
> ...would be more robust, though.  :)
>
> > Thank you very much for the hint regarding .fam,
>
> And I wanted to compliment you on your document.  It is _exactly_ the
> sort of thing I had in mind when I went to the (surprisingly
> troublesome) effort of refactoring localization support to make English
> and its hyphenation patterns merely a default as opposed to something
> bolted more firmly into the system.
>
> I had visions of people switching between multiple languages smoothly,
> with appropriate hyphenation patterns being loaded and unloaded, and the

Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

[John Gardner]

>
>  Yes.  Though it contains device-dependent troff output.  :-)
>

Aye, but most folks would find that less confusing than a format named
after a fish … ;-)


>  The ‘dit’ suffix is probably what I've seen the most.
>

Same, although I personally prefer to use .ditroff for long-term storage of
ditroff source (say, a fixture tracked by version control).


> Also, the ‘out’ seems wrong. So many files are the output of something yet
> don't have that in their suffix.  a.out seems to have that honour as it
> nabbed it first.


Agreed. I also see *.out and *.err files generated by unit-tests that dump
their stdout and stderr streams (respectively). On a related note, I used
to use .out as the file-extension of Roff.js's test-fixtures. I later
regretted that when I added fixtures for Osanna troff's output (raw binary
containing C/A/T driver instructions). Though in hindsight, *.cat was
probably a better choice of extension…

On Sun, 9 Apr 2023 at 02:48, Ralph Corderoy  wrote:

> Hi John,
>
> > I've always just called it "ditroff" (*"device-independent troff
> > [output]"*), with *.dit and *.ditroff being my typical choice of file
> > extensions.
>
> The ‘dit’ suffix is probably what I've seen the most.
>
> > I'm aware that it's a reappropriation of an obsolete name for all
> > post-Osanna troff(1) implementations, but its meaning is clearer to
> > readers familiar with the term *"device-independent [gt]roff output"*.
>
> Yes.  Though it contains device-dependent troff output.  :-)
>
> > The names "grout" and "trout", OTOH, are a lot less obvious.
>
> Also, the ‘out’ seems wrong.  So many files are the output of something
> yet don't have that in their suffix.  a.out seems to have that honour as
> it nabbed it first.
>
> The file contains a rendering of the troff for a device.
> In case that helps trigger better suggestions.
>
> --
> Cheers, Ralph.
>
>

Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

[John Gardner]

Hi Branden,


> I know I will be mightily tempted to encourage others to adopt the
> practice, in large part because "device-independent [gt]roff] output" is
> far too long to type or speak repeatedly.


I've always just called it "ditroff" (*"device-independent troff [output]"*),
with *.dit and *.ditroff being my typical choice of file extensions. I'm
aware that it's a reappropriation of an obsolete name for all post-Osanna
troff(1) implementations, but its meaning is clearer to readers familiar
with the term *"device-independent [gt]roff output"*. The names "grout" and
"trout", OTOH, are a lot less obvious. Not to mention they'll be used
interchangeably and inconsistently à la nroff/groff/troff).

On Fri, 7 Apr 2023 at 12:26, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2023-04-06T10:39:13+, Lennart Jablonka wrote:
> > Then comes the noteworthy bit: Concatenate the troff output of all
> > those separate documents and feed it all to the postprocessor at once,
> > as in
> >
> >   troff -ms mainmatter.ms >mainmatter.trout 2>toc
> >   { troff frontmatter && troff toc && cat mainmatter.trout;   }
> | gropdf
> > >all.pdf
> >
> > That’s what I would do.
>
> I must say I am delighted to see that it has occurred to someone else to
> use the suffixes "trout" (and presumably "grout") for device-independent
> troff and GNU roff output.
>
> When I get around to my planned soup-to-nuts revision of groff_out(5), I
> know I will be mightily tempted to encourage others to adopt the
> practice, in large part because "device-independent [gt]roff] output" is
> far too long to type or speak repeatedly.
>
> Regards,
> Branden
>

Re: [Optional] versus parameters

[John Gardner]

Hi Branden,

Documentation cowboys think they're being cool when they cram all this shit
> onto one logical synopsis line.
>

Synopses for command-line programs (i.e., man pages allocated to sections 1
or 8) are only a small part of the problem. When documenting file formats,
configuration files, schemata, and APIs written in languages other than
C/C++, the need to delineate alias groups becomes much more prevalent.

On an unrelated note, I've recently found myself using the same stylistic
conventions used in man pages for denoting *literal* and *placeholder* text
in syntax descriptions (specifically those containing expository characters
like brackets and pipes, which users aren't expected to type). The most
recent
<https://github.com/Cutlery-Drawer/simh/blob/a8fd111bc28c5e5fd72e4514d60723f3169e4d49/doc/altairz80_doc.rst#id11>
case involves reStructuredText files which will be used to generate man
pages using Sphinx <https://www.sphinx-doc.org/>, so the font choices are
still somehow relevant…

(Anywho, sorry for the long-winded rambling…)
— John

On Wed, 22 Feb 2023 at 17:06, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> I think I can speak to this.
>
> At 2023-02-22T16:24:33+1100, John Gardner wrote:
> > What's the recommended convention for marking up *required* arguments?
> > Square brackets indicate optional arguments more often than not, and
> > something like this is ambiguous to readers:
> >
> > *upgrade* | *update* *package*
>
> Yes.
>
> > This could be interpreted in two different ways (expressed using BNF):
> >
> >  := ("upgrade" | "update") 
> > Or
> >  := ("upgrade" | "update" )
>
> Yes.
>
> Normally, mandatory (required) arguments get no special markup.
> However, as you note, sometimes selection among a group of mandatory
> arguments is possible (or necessary).
>
> In groff_man(7), I used to advise braces in for this type of situation.
>
> k00lzip {--create | --extract | --test} [-abdeg] [-f archive] member ...
>
> But I no longer do; instead, I decided it was clearer to the user to
> have multiple synopses for this situation.
>
> Here's what groff_man_style(7) says today.
>
>   Command synopsis macros
> .SY and .YS aid you to construct a command synopsis that has the
> classical Unix appearance.  They break the output line.
> ...
> .SY command
> Begin synopsis.  A new paragraph begins at the left margin (as
> with .P) unless .SY has already been called without a
> corresponding .YS, in which case only a break is performed.
> Automatic hyphenation is disabled.  command is set in bold.  If
> a break is required, lines after the first are indented by the
> width of command plus a space.
>
> .YS End synopsis.  The previous indentation amount and initial
> hyphenation mode are restored.
>
> Multiple .SY/.YS blocks can be specified, for instance to
> distinguish differing modes of operation of a complex command like
> tar(1); each will be vertically separated as paragraphs are.
>
> .SY can be repeated before .YS to indicate synonymous ways of
> invoking a particular mode of operation.
>
> Particularly with commands that have a rich (crusty old codgers of all
> ages would say "excessive") option interface, it can be overwhelming to
> present multiple mandatory "options" along with several discretionary
> ones.
>
> This gets worse in terms of visual and conceptual clutter when any of
> the options, mandatory or not, takes arguments.
>
> And things become downright _unclear_ when _some_ of the discretionary
> options are only meaningful with certain selections of the mandatory
> ones.
>
> Documentation cowboys think they're being cool when they cram all this
> shit onto one logical synopsis line.  (It rarely all fits on a physical
> one.)
>
> Consider grotty(1), which takes one set of (truly optional) options when
> it's running in overstriking (Teletype compatibility) mode, and a subset
> of those when it emits SGR escape sequences, along with a couple of
> others that are meaningless in overstriking mode.
>
> Synopsis
> grotty [-dfho] [-i|-r] [-F dir] [file ...]
>
> grotty -c [-bBdfhouU] [-F dir] [file ...]
>
> grotty --help
>
> grotty -v
> grotty --version
>
> Ingo has suggested that it is excessive to document the help and version
> options, but the splitting of the first two, I'll defend while quoting
> Milton and Melville with my arms wrapped around a Genesis device.
>
> Regards,
> Branden
>

[Optional] versus parameters

[John Gardner]

What's the recommended convention for marking up *required* arguments?
Square brackets indicate optional arguments more often than not, and
something like this is ambiguous to readers:

*upgrade* | *update* *package*

This could be interpreted in two different ways (expressed using BNF):

 := ("upgrade" | "update") 
Or
 := ("upgrade" | "update" )

Angle brackets seem to be the prevailing convention in usage messages,
--help output, and plain-text option summaries. However, I rarely ever see
this used in orthodox man pages: mdoc(7) has various enclosure macros like
.Aq, .Brq, .Pq *et al*, but nothing like its .Op macro, which semantically
identifies its contents as "optional" in the context of wherever it's used.

I know I'm overthinking this, but this is something that's been eating away
at me every time I've resorted to using square-brackets as a logical
grouping mechanism; i.e., stuff like

[[*upgrade* | *update*] *package*]

How have other folks dealt with this issue? (If at all).

Regards,
— John

Re: groff 1.23.0.rc3 available for testing

[John Gardner]

This builds faithfully on macOS with no hassles whatsoever (using `./configure
&& make -j4 && make check && make install`).

Unfortunately, its man pages will remain unreadable on most sites unless we
deal with mandoc(1)'s mangling of the new man(7) macros. Even if Ingo were
to fix this today, there'd still be a considerable window between now and
when Apple update macOS's version of mandoc(1).

On Tue, 21 Feb 2023 at 09:39, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> groff 1.23 release candidate 3, 1.23.0.rc3, is now available from GNU's
> alpha site.  You may download the distribution archive from there.
>
>   https://alpha.gnu.org/gnu/groff/
>
> What is groff?
> ==
>
> groff (GNU roff) is a typesetting system that reads plain text input
> files that include formatting commands to produce output in PostScript,
> PDF, HTML, or DVI formats or for display to a terminal.  Formatting
> commands can be low-level typesetting primitives, macros from a
> supplied package, or user-defined macros.  All three approaches can be
> combined.
>
> A reimplementation and extension of the typesetter from AT&T Unix, groff
> is present on most POSIX systems owing to its long association with Unix
> manuals (including man pages).  It and its predecessor are notable for
> their production of several best-selling software engineering texts.
> groff is capable of producing typographically sophisticated documents
> while consuming minimal system resources.
>
>   https://www.gnu.org/software/groff/
>
> Changes
> ===
>
> Release candidate 3 resolves a build problem on macOS 12, fixes several
> automated test failures on non-GNU/Linux hosts, improves gropdf's
> parsing of "papersize" directives in "DESC" files, and clarifies and
> corrects documentation.
>
> Since groff 1.22.4 was released in December 2018, 26 people have made a
> total of over 4,500 commits.
>
> $ git shortlog --summary --email 1.22.4..1.23.0.rc3
> 14  Bertrand Garrigues
> 14  Bjarni Ingi Gislason
>  6  Colin Watson
>  1  Cynthia A. E. Livingston
>  1  Damian McGuckin
>     30  Dave Kemper
> 28  Deri James
>  2  Dorai Sitaram
>  1  Edmond Orignac
>  1  Eric Allman
>   4419  G. Branden Robinson
>  1  George HELFFRICH
> 33  Ingo Schwarze
>  1  John Gardner
>  4  Keith Bostic
> 25  Keith Marshall
>  2  Michael J. Karels
>  1  Nate Bargmann
>  3  Nikita Ivanov
>  1  Paul Eggert
> 66  Peter Schaffter
>  1  Samanta Navarro
>  1  T. Kurt Bond
>  3  Tadziu Hoffmann
>  2  ivan tkachenko
>  1  наб
>
> (Some possibly surprising names in the above are due to a rebase of
> groff me(7) against 4.4BSD.)
>
> Headline features nominated by our development community include:
>   * a new 'man' macro, "MR", for formatting man page cross references;
>   * hyperlinked text in terminals via the ECMA-48 OSC 8 escape sequence;
>   * a new 'rfc1345' macro package, contributed by Dorai Sitaram,
> enabling use of RFC 1345 mnemonics as groff special characters;
>   * a new 'sboxes' macro package, contributed by Deri James, enabling
> 'ms' documents to place shaded and/or bordered rectangles underneath
> any groff page elements (PDF output only);
>   * 'mom' 2.5, a macro package contributed by Peter Schaffter;
>   * the 'ms' package's new strings to assist subscripting;
>   * Italian localization, including hyphenation patterns and macro
> package string translations, thanks to Edmond Orignac; and
>   * new hyphenation patterns for English.
>
> For more on these and other feature changes, see "News" below.
>
> Much attention has been given to fixing bugs, improving diagnostic
> messages, and correcting and expanding documentation.  The previous
> release shipped with three automated unit tests; this one ships with
> over 160 unit and regression tests.
>
> As of this writing, per the GNU Savannah bug tracker, the groff project
> has resolved 416 problems as fixed for the 1.23.0 release.  Some of the
> bugs we've corrected were over 30 years old.
>
> Classifying these issues by type and the component of the project to
> which they apply, we find the following.
>
>   Type  Component
>     -
>   Build/installation   39   Core   96
>   Crash/unresponsive   11   Driver: grohtml 7
>   Documentation   101   Driver: gropdf  9
>   Feat

Re: rc3: groff man pages truncated by mandoc(1)

[John Gardner]

Hi Branden,


> If I could do something like the following:
>
> .if \n[.mandoc] .als MR IR
>

To determine if mandoc(1) is being used to format the current page, use

.if \n(.f=0

This is what Mono.tmac

uses to identify mandoc(1), and it works quite well: no full Troff
implementation will mount a font at a position of zero, and mandoc(1) has
absolutely no concept of mounting fonts, period.

Regards,
— John

On Tue, 21 Feb 2023 at 20:19, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Alexis,
>
> At 2023-02-21T19:02:14+1100, Alexis wrote:
> > i've just installed rc3 via the relevant Gentoo ebuild. My Gentoo
> > system is mandoc-based, via the `system-man` USE flag.
> >
> > Running `man` - actually the `mandoc` binary - still works fine
> > overall, but not with the new groff man pages. For example, `man
> > groff_man_style` produces this as the entirety of its output:
> >
> > --- ✂ ---
> > groff_man_style(7) Miscellaneous Information Manual
> groff_man_style(7)
> >
> > Name
> >   groff_man_style - GNU roff man page tutorial and style   guide
> >
> > groff 1.23.0.rc3   21 February 2023 groff_man_style(7)
> > --- ✂ ---
>
> I can reproduce this (with mandoc 1.14.5-1 in Debian bullseye).
>
> > On the other hand, `groff -man -Tutf8
> /usr/share/man/man7/groff_man_style.7`
> > works just fine.
>
> Yes.  (You'll want a "-t" in there too, for the tables.)
>
> > Is there something in 1.23 that mandoc needs to be updated to support?
>
> Yes.  And it's something mandoc maintainer Ingo Schwarze doesn't really
> want to support.  Or, at least, my recollection is that he expressed
> great reluctance about doing so the last time he participated in a
> discussion of it on this list.  It's been some months since we've seen
> him, sadly.  It was just about the time I started making edits to the
> groff_mdoc(7) man page...
>
> Ironically enough, it was a recent change (see below) taking into
> account Ingo's advice for how to proceed with what he considered an
> ill-advised new macro (MR) that has caused the groff man pages to
> malfunction so badly with mandoc(1).
>
> A sufficiently enthusiastic mandoc partisan may consider this a feature,
> not a bug, if it drives people away from using groff at all...
>
> > Or, more likely, am i just doing something wrong, or not doing
> > something right?
>
> Nope, you did nothing wrong.
>
> You can take out the following material from groff man pages:
>
> .\" Define fallback for groff 1.23's MR macro if the system lacks it.
> .de @@
> .  de MR
> .ie \n(.$=1 \
> .  I %\$1
> .el \
> .  IR %\$1 (\$2)\$3
> .  \\.
> ..
> .if  \n(.g .if !d MR .@@
> .if !\n(.g .@@
> .rm @@
>
> (*roff experts: yes, there is a stupid mistake in the above[1].  I will
> fix it.)
>
> ...and a lot more will render, but crucially, the man page cross
> references will be gone, which is why I put in the above hack in the
> first place (on 3 February[2]), and which I would like to dispose of for
> groff 1.24 or so.
>
> While I'm unhappy to see mandoc(1) doing this, I think it's preferable
> to the _subtle_ omission of man page cross references.  With the
> severely truncated output you're seeing, it is at least obvious to the
> user that something is wrong.
>
> mandoc is not a true *roff language interpreter, so I am not aware of
> anything I can do in the groff man pages to work around mandoc's lack of
> support for this feature.
>
> If I could do something like the following:
>
> .if \n[.mandoc] .als MR IR
>
> ...in groff's man pages to accommodate mandoc(1), I would, happily.  But
> mandoc, to the best of my knowledge, simply isn't designed to do things
> like alias macros.
>
> Incidentally, I don't blame mandoc(1) for not being able to parse that
> stuff I pasted up there.
>
> This is a problem, and I don't think it can be resolved without help
> from mandoc(1).  The alternative--ripping out what I consider to be
> groff 1.23 man(7)'s signature feature--is not something I am willing to
> do (see the "News" item in the RC3 announcement for why I think `MR` is
> important).
>
> There is a set of people who feel that man pages should be composed only
> in mdoc(7) and rendered only with mandoc(1).  I am not one of them.
>
> The easiest thing for mandoc(1) to do is to treat `MR` as a near synonym
> of `IR` (or `BR`), slapping parentheses around the second argument.  It
> does not have to do any of the hyperlinking or OSC 8 stuff that groff's
> implementation does.  I have no problem working on (and, if successful,
> contributing) a patch for this, but I have two major tasks in my queue
> _after_ groff 1.23.0 final to take care of first.
>
> Thank you very much for raising this issue before the final release;
> this is an important matter that needs to be warned about in the
> announcement.
>
> If you'd like to share your/a surname, I can credit you by your full
> name as a co

Re: A version of fmt for troff files

[John Gardner]

>
> https://en.roquesor.com/Downloads/fmtroff.c
>

Missed opportunity to call it "roffmt". ;-)

Anyway, I fed the program a macro package with the -n switch passed, and
it... basically mangled the entire file. I take it that fmtroff is only
designed to format prose, rather than Roff code (macros, et al)?

Tested under OpenBSD and Linux.  You should be able to compile it under any
> of these OSs.
>

Compiles without a hitch on macOS too, FYI.

On Fri, 17 Feb 2023 at 20:58, Walter Alejandro Iglesias 
wrote:

> Hello everyone,
>
> I've been using groff to format my novels since years.  Lately I wrote
> my own version of fmt with some feature added to format troff files (in
> the head comment of the code I explain its features in more detail.)  I
> decided to share it here, perhaps some of you find it useful:
>
>   https://en.roquesor.com/Downloads/fmtroff.c
>
> Tested under OpenBSD and Linux.  You should be able to compile it under
> any of these OSs.
>
> I take this opportunity to thank developers for maintaining this great
> software!
>
>
> --
> Walter
>
>

Re: macOS Terminal man page URL format

[John Gardner]

Hi Branden,

> $ (unset GROFF_TYPESETTER; make -j check)

I ran `GROFF_TYPESETTER= make check` and—as I expected—the tests passed.

> I don't agree; when writing a test suite, one should eliminate as many
> confounding variables (in the experimental sense) as possible

Yes, which is why I suggested they be *un*set before running the tests. You
may have misread what I wrote… ;-)

— J

On Thu, 16 Feb 2023 at 15:44, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2023-02-16T15:34:57+1100, John Gardner wrote:
> > > ...wait.  Did you configure your groff build to use one of the
> > > terminal devices as the default typesetter?  Or maybe you have
> > > GROFF_TYPESETTER set a terminal device in the environment?
> >
> > I do, actually
> > <
> https://github.com/Alhadis/.files/blob/bee70cfd0d9a2343b68fe83d61967610b3e66f9d/env.sh#L59
> >.
> > It's set to utf8, which has historically been necessary on macOS to
> > enable UTF-8 characters in man pages.
>
> Hmm.  Not the level at which I'd solve the problem personally (I read
> UTF-8-enriched man pages every day without setting GROFF_TYPESETTER),
> but you're not doing anything unsupported or even discouraged.
>
> > > If that starts dinging the bell, then what I need to do is add a "-T
> > > ps" argument to these tests.
> >
> > Or unset/override pertinent environment variables before running the
> > tests, which is How I'd Do It™.
>
> I don't agree; when writing a test suite, one should eliminate as many
> confounding variables (in the experimental sense) as possible; I failed
> to do so here.
>
> The $64,000 question is whether unsetting GROFF_TYPESETTER and
> re-running the test cures the failure.
>
> $ (unset GROFF_TYPESETTER; make -j check)
>
> Let me know, and I can land this fix.
>
> ...and get back to the more complicated problem I'm working (but maybe
> in the morning).
>
> https://savannah.gnu.org/bugs/?63808
>
> Regards,
> Branden
>

Re: macOS Terminal man page URL format

[John Gardner]

> ...wait.  Did you configure your groff build to use one of the terminal
> devices as the default typesetter?  Or maybe you have GROFF_TYPESETTER
> set a terminal device in the environment?

I do, actually
<https://github.com/Alhadis/.files/blob/bee70cfd0d9a2343b68fe83d61967610b3e66f9d/env.sh#L59>.
It's set to utf8, which has historically been necessary on macOS to enable
UTF-8 characters in man pages.

> If that starts dinging the bell, then what I need to do is add a "-T ps"
argument to these tests.

Or unset/override pertinent environment variables before running the tests,
which is How I'd Do It™.

On Thu, 16 Feb 2023 at 15:30, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-16T15:09:06+1100, John Gardner wrote:
> > Many thanks. All but one of the tests are passing now, which is the
> > same one you're having troubles reproducing the failure of:
> >
> > > > FAIL: tmac/tests/an_use-input-traps-correctly.sh
> > >
> > > I found this very weird but I could not reproduce this test failure on
> a
> > > macOS system.
> >
> > I've logged the contents of the $output variable for each failing test
> > (something that I expected to be included in test-suite.log, but
> > isn't):
>
> ...I haven't been entirely consistent about doing that.  I don't think
> it's always appropriate, since some tests can produce a lot of output.
>
> > checking that SM macro uses correct input trap 'it'
> > ...FAILED
> >
> > 
> > foo(1) General Commands Manual foo(1)
> > 1010
> > groff test suite 2022-06-07 foo(1)
> >
> > checking that SB macro uses correct input trap 'it'
> > ...FAILED
> >
> > 
> > foo(1) General Commands Manual foo(1)
> > B10R10
> > groff test suite 2022-06-07 foo(1)
>
> Okay, so here's what the sources of those tests look like.
>
> --snip--
> # SM
>
> input=".TH foo 1 2022-06-07 \"groff test suite\"
> .SM n[.s]\c
> \\n[.s]"
>
> output=$(printf "%s\n" "$input" | "$groff" -man -a 2>&1)
>
> echo "checking that SM macro uses correct input trap 'it'" >&2
> echo "$output" | grep -Fqx '910' || wail
>
> # SB
>
> input=".TH foo 1 2022-06-07 \"groff test suite\"
> .SB n[.fn]n[.s]\c
> \\n[.fn]\\n[.s]"
>
> output=$(printf "%s\n" "$input" | "$groff" -man -a 2>&1)
>
> echo "checking that SB macro uses correct input trap 'it'" >&2
> echo "$output" | grep -Fqx 'TB9TR10' || wail
> --end snip--
>
> What we're doing is telling the formatter to embed the type size (in
> points) and, in the second test, the groff font name as well into the
> output.
>
> groff(7) says:
> \n[.s] Type size in points as a decimal fraction (string‐
>valued).  see .ps and \s.
> \n[.fn]Resolved name of selected font (string‐valued); see
>.ft and \f.
>
> Here is a grid summarizing the situation.
>
> test | expected output | your output
> SM   | 910 | 1010
> SB   | TB9TR10 | B10R10
>
> That's quite bizarre.  So let's look at the macros themselves next.
>
> --snip--
> .\" Set arguments (or next input line producing written or drawn output
> .\" if none) at smaller type size.
> .de1 SM
> .  it 1 an-input-trap
> .  ps -1
> .  if \\n[.$] \&\\$*
> ..
> .
> .\" Set arguments (or next input line producing written or drawn output
> .\" if none) in bold style at smaller type size.
> .de1 SB
> .  it 1 an-input-trap
> .  ps -1
> .  ft B
> .  if \\n[.$] \&\\$*
> ..
> --end snip--
>
> So, it's like type size changes are being outright refused, and font
> families utterly ignored.  Those are things only nroff devices do...
>
> ...wait.  Did you configure your groff build to use one of the terminal
> devices as the default typesetter?  Or maybe you have GROFF_TYPESETTER
> set a terminal device in the environment?
>
> If that starts dinging the bell, then what I need to do is add a "-T ps"
> argument to these tests.
>
> Regards,
> Branden
>

Re: macOS Terminal man page URL format

[John Gardner]

Hi Branden,

I've pushed fixes for these.
>

Many thanks. All but one of the tests are passing now, which is the same
one you're having troubles reproducing the failure of:

> > FAIL: tmac/tests/an_use-input-traps-correctly.sh
>
> I found this very weird but I could not reproduce this test failure on a
macOS system.

I've logged the contents of the $output variable for each failing test
(something that I expected to be included in test-suite.log, but isn't):

checking that SM macro uses correct input trap 'it'
...FAILED


foo(1) General Commands Manual foo(1)
1010
groff test suite 2022-06-07 foo(1)

checking that SB macro uses correct input trap 'it'
...FAILED


foo(1) General Commands Manual foo(1)
B10R10
groff test suite 2022-06-07 foo(1)

— John

On Tue, 14 Feb 2023 at 13:59, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-11T10:19:08+1100, John Gardner wrote:
> > However, when I ran `make check` in my checkout directory, 7 of the
> > tests failed (full details in the attached log file):
> >
> > FAIL: tmac/tests/an_use-input-traps-correctly.sh
>
> I found this very weird but I could not reproduce this test failure on a
> macOS system.
>
> > FAIL: src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
> > FAIL: tmac/tests/an_TS-adds-no-vertical-space.sh
> > FAIL: tmac/tests/doc_heading-font-remapping-works.sh
>
> I've pushed fixes for these.
>
> > FAIL: tmac/tests/latin2_works.sh
> > FAIL: tmac/tests/latin5_works.sh
> > FAIL: tmac/tests/latin9_works.sh
>
> I have fixes for these pending.
>
> Regards,
> Branden
>

Re: "make check" failing on macOS (was: macOS Terminal man page URL format)

[John Gardner]

>
> I just want to compare 2 byte streams in a shell script without using
> temporary files.


Just out of curiosity: why? The test directory is already polluted with
artefacts during the course of the test-run: I don't see why creating a few
more is burdensome.

In any case, the difference between GNU od(1) and BSD od(1) is that the
latter preserves trailing whitespace:

GNU:
│0x│ 30 30 30 30 30 30 30 20 20 20 41 20 20 5C 62 20 │000   A
 \b │
│0x0010│ 20 20 42 20 20 5C 62 20 20 20 43 20 20 20 20 20 │  B  \b   C
  │
│0x0020│ 20 20 44 20 20 5C 6E 0A 30 30 30 30 30 31 30│  D
 \n.010 │

BSD:
│0x│ 30 30 30 30 30 30 30 20 20 20 20 41 20 20 5C 62 │000A
 \b│
│0x0010│ 20 20 20 42 20 20 5C 62 20 20 20 43 20 20 20 20 │   B  \b   C
   │
│0x0020│ 20 20 20 44 20 20 5C 6E 20 20 20 20 20 20 20 20 │   D  \n
   │
│0x0030│ 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 │
   │
│0x0040│ 20 20 20 20 20 20 20 20 0A 30 30 30 30 30 31 30 │
 .010│

Ergo, simply appending ` *` to your grep(1) expression should be enough to
accommodate both flavours.

On Sat, 11 Feb 2023 at 12:23, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-11T10:19:08+1100, John Gardner wrote:
> > Yes, it builds successfully now (macOS 12.6.3). I ran `make install`
> > and the installed Groff seems to be working perfectly.
>
> Excellent!
>
> > However, when I ran `make check` in my checkout directory, 7 of the
> > tests failed (full details in the attached log file):
> [...]
> > Are these normal?
>
> Certainly not.
>
> > I'm attaching my build logs just in case.
>
> Thank you--this is helpful.  Some or all of these problems I think we
> have seen on macOS before; they involve the portability of shell syntax
> and of a few (incompletely) standardized tools.  xooglers "just want to
> serve 5 terabytes".  I just want to compare 2 byte streams in a shell
> script without using temporary files.  Astoundingly, this is way harder
> and system-dependent than it should be.  I attribute that to the early
> mentality that the PDP-11 was the only machine that mattered, and the
> belief of the succeeding generation, despite obvious contrary evidence,
> that the VAX was the only machine that mattered.
>
> Nowadays, we laugh at the blinkered folly of our ancestors and
> confidently understand that x86-64 is all that matters.
>
> > FAIL: src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
>
> "od -t c".  If I remember correctly, macOS od produces output unlike
> both Unix Version 7 od and GNU od.  Certainly macOS and GNU od don't
> agree with each other.
>
> > FAIL: tmac/tests/an_TS-adds-no-vertical-space.sh
>
> sed.  I'll have to look up what hoop is required for macOS sed, which I
> think comes from one of the BSDs but, as I recall, proudly refuses to
> admit any means of identifying itself by version number in execution.
> (That's for disgusting things like GNU programs.)
>
> > FAIL: tmac/tests/an_use-input-traps-correctly.sh
>
> This looks like a shell difference in how sequences of backslashes are
> interpreted in double-quoted strings.  I see no variable interpolations
> in the cases in question, so I may be able to fix this by just making
> the strings single-quoted.
>
> > FAIL: tmac/tests/doc_heading-font-remapping-works.sh
>
> sed again.  It seems to think I am using GNU extensions, but I'm not
> using any marked as such in GNU sed's man page.  Maybe it's a BRE vs.
> ERE thing.  POSIX prescribes a -E option for this.  I'm sure the sed on
> Solaris 10 doesn't support it.  :-|
>
> > FAIL: tmac/tests/latin2_works.sh
> > FAIL: tmac/tests/latin5_works.sh
> > FAIL: tmac/tests/latin9_works.sh
>
> "od -t c" again.
>
> This is useful information, even if it fuels my frustration with
> vendors of fundamental Unix utilities.  I'll see what I can do.
>
> Regards,
> Branden
>

Re: macOS Terminal man page URL format

[John Gardner]

Knowing Apple, the *x-man-page://* scheme was intended for internal use
between userland programs; a similar protocol exists for looking up a
word's definition: *x-dictionary:harangue*. However, the nature of macOS's
LaunchServices makes it impossible (or at least incredibly difficult) for
any supported URL scheme to be hidden from users. People likely
"discovered" x-man-page whilst snooping through files such as
~/Library/Preferences/com.apple.LaunchServices/com.apple.launchservices.secure.plist
.

Regardless of the scheme's origin, the likelihood of Apple dropping support
forit is precisely zero. macOS inherits a load of weirdness for the sake of
legacy compatibility, which natrally includes schemes like x-man-page. This
doesn't mean man:page(1) and x-man-page://1/page won't some day be
supported side-by-side, however.

In any case, I just realised there's a much bigger hurdle: macOS switched
to mandoc(1) in version 11 (November 2020), and patched their /usr/bin/man
binary to use hardcoded paths like /usr/bin/mandoc. The exact changes Apple
made to man-1.6g can be examined on GitHub
<https://github.com/apple-oss-distributions/man/compare/d1a6cf2..34c45d6>
(or by running `git show d1a6cf2...34c45d6
<https://github.com/apple-oss-distributions/man/compare/d1a6cf2..34c45d6>`
on a local checkout of the apple-oss-distributions/man
<https://github.com/apple-oss-distributions/man> mirror). So, erh, yeah…
this complicates things…

You can see that I'd very much like to get into an argument with whoever
> coded this into Terminal.app in the first place.
>

It's not so much a part of Terminal.app as it is the default handler for
x-man-page URLs (in the same way that Thunderbird handles mailto: URLs).
It's theoretically possible to register a different app, although the
procedure appears complicated (and I've yet to read up on it myself: it's
on my to-do list under *"Weaponise lsappinfo(8)"*).


On Tue, 7 Feb 2023 at 08:03, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-07T07:24:52+1100, John Gardner wrote:
> [I wrote:]
> > > I would prefer to hold macOS up to ridicule in this respect in hopes
> > > of motivating its users (and developers) to standardize on
> > > something.
> >
> > By "standardise", are you specifically referring to a *de jure*
> > standard?
>
> Well, nearly as _jure_ as we get in Internet world, which I guess would
> be an RFC.  (This doesn't really seem like POSIX's bailiwick, but they
> do produce a true standard.)
>
> > macOS's x-man-page:// scheme is only a *de facto* standard, but it's
> > by far the oldest, best-known, and widely-supported man-page URL
> > scheme on macOS, even recently.
>
> Okay.  I don't aim to not support it so much as harangue Apple partisans
> into calling for man:page(section) support in Terminal.app...so that I
> can, at some point down the road, _then_ unsupport x-man-page.  The
> leading "x-" acknowledges that it was a stopgap measure, or I miss my
> guess.  (It is reminiscent of nonstandard MIME types.)  I see that the
> "x-" prefix itself is now, apparently, deprecated[1], and more to the
> point, the scheme part of a URL is not an appropriate place to express
> the _content_ of a delivered data stream, but rather the _transport
> mechanism_ by which it is fulfilled.
>
> What is the mechanism by which a man page is resolved to a deliverable
> document, given a page name and section identifier?
>
> Why, that would be the "man" librarian program.
>
> The availability of something that delivers the man page document to a
> browser is implied by the fact of its encoding in a URL in the first
> place.
>
> You can see that I'd very much like to get into an argument with whoever
> coded this into Terminal.app in the first place.  I expect either a
> sheepish admission that something intended as a quick hack raged out of
> control (I've had those, and I am loath to name them), or to find
> someone with a cowboy hat and a lot of bullshit to peddle.
>
> > Yes, but you have actually encountered these in practical experience.
> >
> > It wasn't a practical encounter. I was actively researching how
> > authors have approached the issue of man-page hyperlinks in the past
> > (not just on macOS, but *any* Unix-like system). I did this to make
> > Roff.js's URI handling functions as airtight as possible.
>
> That _is_ practice, my good sir.  Your did your homework in service of
> pursuing a clean design.
>
> > BTW, what file should I apply your patch to? I'm getting an error when
> > I > attempt to apply it:
> >
> &

Re: macOS Terminal man page URL format

[John Gardner]

>
> I would prefer to hold macOS up to ridicule in this respect in hopes of
> motivating its users (and developers) to standardize on something.


By "standardise", are you specifically referring to a *de jure* standard?
macOS's x-man-page:// scheme is only a *de facto* standard, but it's by far
the oldest, best-known, and widely-supported man-page URL scheme on macOS,
even recently.

Yes, but you have actually encountered these in practical experience.


It wasn't a practical encounter. I was actively researching how authors
have approached the issue of man-page hyperlinks in the past (not just on
macOS, but *any* Unix-like system). I did this to make Roff.js's URI
handling functions as airtight as possible.

That creates more places for something to go wrong.
>

Yeah, true. Forget about the callback idea, then. :-)

BTW, what file should I apply your patch to? I'm getting an error when I
attempt to apply it:

$ git apply ~/Downloads/macOS-man-grief.diff
error: patch failed: tmac/man.local:14
error: tmac/man.local: patch does not apply

Remember, this is with the latest Groff sources, which still aren't
building successfully on macOS…

On Tue, 7 Feb 2023 at 06:55, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-07T06:26:22+1100, John Gardner wrote:
> > Then how about a callback? It could be called with the relevant
> > parameters, and authors can use plain ol' Roff to specify the
> > hyperlink format.
>
> That creates more places for something to go wrong.  Also I don't want
> people to get the idea that they should be defining this callback _in
> the man page document_.  That is very much the wrong way to go.
>
> > I think we're on two different pages here. That last list of URL
> > formats was intended to illustrate the potential for variation amidst
> > software authors. It's very easy for somebody to "invent" their own
> > man page URL scheme, one that may be partially- or wholly-incompatible
> > with other, better-established schemes.
>
> Yes, but you have actually encountered these in practical experience.
>
> > Ultimately, only Terminal.app's scheme (x-man-page://) should be taken
> > seriously by Groff.
>
> I would prefer to hold macOS up to ridicule in this respect in hopes of
> motivating its users (and developers) to standardize on something.[1]
> What I'm calling "format 1" would be best, but I know that NIH syndrome
> dominates a lot of corporate software development.  And some elsewhere.
>
> If I had to use macOS for some reason, I'd go out of my way to use xterm
> rather than Terminal.app.  Lack of man page hyperlinks is not a deal-
> breaker for me personally.  I have not begun a campaign to talk Thomas
> Dickey into supporting OSC 8 in xterm.  I do not expect it to be easy.
>
> > > apropos(1) is not in groff's department.
> >
> > Right, sorry. I keep getting my wires crossed when discussing man(1)
> > and Groff at once…
>
> No worries.  I think a lot of people are fuzzy about the distinction, so
> opportunities like this to set the record straight are to be seized. :)
>
> Regards,
> Branden
>
> [1] You can see that I'd be brilliant in corporate communications.
>

Re: macOS Terminal man page URL format

[John Gardner]

Hi Branden,


Having a configurable prefix/schema isn't going to cut it.
>

Then how about a callback? It could be called with the relevant parameters,
and authors can use plain ol' Roff to specify the hyperlink format.

but I have to say I really hate this and I want macOS to get its act
> together.
>

I think we're on two different pages here. That last list of URL formats
was intended to illustrate the potential for variation amidst software
authors. It's very easy for somebody to "invent" their own man page URL
scheme, one that may be partially- or wholly-incompatible with other,
better-established schemes.

Ultimately, only Terminal.app's scheme (x-man-page://) should be taken
seriously by Groff.

apropos(1) is not in groff's department.
>

Right, sorry. I keep getting my wires crossed when discussing man(1) and
Groff at once…

On Tue, 7 Feb 2023 at 05:36, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2023-02-06T18:53:10+1100, John Gardner wrote:
> > While I *strongly* advocate for the man:name(section) syntax (because
> > it essentially dates right back to the earliest man pages), it would
> > be remiss of me to ignore the other formats listed above.
> >
> > > But...ugh!  I don't remember this coming up before, but it could
> > > have.
> >
> > I vaguely recall mentioning it some time ago, although you dismissed
> > it in favour of enforcing a single, consistent URL syntax.
>
> I remember now why I wanted to cast the issue aside, and I'd have
> remembered last night if my brain hadn't wanted me to just go to bed.
>
> > man:name.section  - Bwana(macOS)
> > man:name(section) - GNOME, KDE   (Linux)
> > x-man-doc://3/printf(3)   - ManOpen  (macOS)
> > x-man-page://section/name - Terminal.app (macOS 10.3+)
>
> Having a configurable prefix/schema isn't going to cut it.  The entire
> form of the URL has to be changed.  Double ugh!  And the schema doesn't
> unambiguously indicate the remainder of the URL format.  Triple ugh!
>
> I'll do something simple to limp us over the finish line, but I have to
> say I really hate this and I want macOS to get its act together.  Which
> Apple will almost certainly do by contriving the most rest-of-world-
> ostile and -incompatible alternative it can.  (Whither went that
> that boldly conformist, "let's embrace the world's worst ISA" attitude
> of the 2005 WWDC?)
>
> Well, at least BSD partisans will get a kick out of that, even if it's
> Pareto-shitty for everyone else.  Somewhere, Charles Hannum laughs.
>
> Regards,
> Branden
>

Re: macOS Terminal man page URL format

[John Gardner]

>
> And since it's specific to the macOS Terminal application


It's indicative of a much larger issue — there's no formal, standardised
scheme for man page URLs. I encountered many variants

whilst working on Roff.js:

man:name.section  - Bwana(macOS)
man:name(section) - GNOME, KDE   (Linux)
x-man-doc://3/printf(3)   - ManOpen  (macOS)
x-man-page://section/name - Terminal.app (macOS 10.3+)

While I *strongly* advocate for the man:name(section) syntax (because it
essentially dates right back to the earliest man pages), it would be remiss
of me to ignore the other formats listed above.

So the exact URL format *does* need to be configurable, preferably with a
separate string for apropos(1) links, if supported (which would logically
default to the `an*MR-scheme` string, or whatever we decide to name it.

But...ugh!  I don't remember this coming up before, but it could have.
>

I vaguely recall mentioning it some time ago, although you dismissed it in
favour of enforcing a single, consistent URL syntax.


> Also, what an ugly convention!
>

Yeah, agreed. Unfortunately, it dates back as far as October 2003, which
means userland tooling has had at least two decades to leverage the syntax.

> Please file a Savannah ticket for this.
>

Wilco.

Re: groff 1.23.0.rc2 available for testing

[John Gardner]

>
> The an (man) macro package can now produce clickable hyperlinks within
> terminal emulators


It might be worth clarifying for macOS users that the hyperlinks use a
protocol incompatible with Apple's: “*man:printf(3)*” is used instead of “
*x-man-page://3/printf*” (the latter scheme is ancient and documented in
detail here

).

If you agree, I can have a crack at documenting a workaround for macOS
users, but since it's essentially an opt-in feature, such a thing might be
overkill at this point. Let me know.

— John


On Mon, 6 Feb 2023 at 02:57, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2023-02-05T13:29:11+, Ralph Corderoy wrote:
> > Some drive-by comments from a quick skim.
>
> Consider getting out of the car and taking the air next time, perhaps...
>
> > > o New requests `soquiet` and `msoquiet` are available.  They operate
> > >   as `so` and `mso`, respectively, except that they do not emit a
> > >   warning diagnostic if the file named in their argument does not
> > >   exist.
> >
> > Given the ‘file’ warning also controls this, AIUI, I wonder if it
> > would have been more orthogonal to have a new command to alter the
> > warnings for just what follows.
> >
> > .warn -file so might-be-missing
> > .warn -el historicalmacro foo bar
>
> Possibly, but (1) the `*quiet` requests are for cases where no strong
> dependency on the sourced file is present and (2) redesigning the `warn`
> interface as you suggest was beyond my ambition at the time (April 2021)
> and would furthermore seem to warrant reconsideration of the warning
> category structure, also beyond my ambition at the time.  As I recall,
> Ingo had much to complain about there.
>
> Here is the syntax summary of the `warn` request from groff(7).  It (the
> feature, not the exact wording below) has looked this way for 30+ years.
> (Warning categories seem to have been implemented prior to groff 0.6.)
>
>.warn Enable all warning categories.
>.warn 0   Disable all warning categories.
>.warn n   Enable warnings in categories whose codes sum to n; see
>  troff(1).
>
> I don't infer the complete meaning of your proposal, either.
>
> > > o nroff now supports spaces and tabs between option flag letters and
> > >   option arguments, like groff and troff themselves.
> >
> > I think that's trying to say
> >
> > nroff -o 3,1,4
> >
> > is now okay, i.e. the option's value can be a separate argument to the
> > option,
>
> Yes.
>
> > but it reads to me that
> >
> > nroff -o' 3,1,4'
> >
> > will ignore the space.  Having to mention spaces and tabs smells wrong.
>
> The file says that nroff "supports" them, not that it "ignores" them, so
> I don't know how you arrived at this reading.
>
> [...]
> > > .am pdfpic@error
> > > .  ab
> > > ..
> [...]
> > > .am pspic@error-hook
> > > .  ab
> > > ..
> >
> > Were those ‘.ab’ written with the lack of a default message in mind?
>
> tmac/pdfpic.tmac says:
>
> .\" A user may wish to append an 'ab' to this macro using 'am'.  That
> .\" is why we don't 'return X' from here to return from two scopes.
> .de pdfpic@error
> .  tm pdfpic.tmac:\\n[.F]:\\n[.c]: error: \\$*
> ..
>
> pspic emits no diagnostics whatsoever.  Would anyone like to write some?
>
> > > o The new rfc1345 macro package, contributed by Dorai Sitaram, defines
> > >   special character identifiers implementing RFC 1345 mnemonics (plus
> > >   some additions from Vim, which itself uses RFC 1345 for its
> digraphs).
> > >   It is documented in the groff_rfc1345(7) man page.
> >
> > Mention ‘digraphs’ earlier and more prominently as that's their common
> > name.
>
> The contents of RFC 1345 and of rfc1345.tmac reveal a problem with this
> claim.
>
> .char \[U:-] \[u01D5]\" LATIN CAPITAL LETTER U WITH DIAERESIS AND
> MACRON
> .char \[u:-] \[u01D6]\" LATIN SMALL LETTER U WITH DIAERESIS AND MACRON
> .char \[U:'] \[u01D7]\" LATIN CAPITAL LETTER U WITH DIAERESIS AND ACUTE
> .char \[u:'] \[u01D8]\" LATIN SMALL LETTER U WITH DIAERESIS AND ACUTE
> .char \[U:<] \[u01D9]\" LATIN CAPITAL LETTER U WITH DIAERESIS AND CARON
> .char \[u:<] \[u01DA]\" LATIN SMALL LETTER U WITH DIAERESIS AND CARON
> .char \[U:!] \[u01DB]\" LATIN CAPITAL LETTER U WITH DIAERESIS AND GRAVE
> .char \[u:!] \[u01DC]\" LATIN SMALL LETTER U WITH DIAERESIS AND GRAVE
> [...]
> .char \[AA'] \[u01FA]\" LATIN CAPITAL LETTER A WITH RING ABOVE AND
> ACUTE
> .char \[aa'] \[u01FB]\" LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE
> .char \[AE'] \[u01FC]\" LATIN CAPITAL LETTER AE WITH ACUTE
> .char \[ae'] \[u01FD]\" LATIN SMALL LETTER AE WITH ACUTE
> .char \[O/'] \[u01FE]\" LATIN CAPITAL LETTER O WITH STROKE AND ACUTE
> .char \[o/'] \[u01FF]\" LATIN SMALL LETTER O WITH STROKE AND ACUTE
> [...]
> .char \[L--.] \[u1E38]\" LATIN CAPITAL LETTER L WITH DOT BELOW 

Re: .ab oddity

[John Gardner]

>
> Something I recommend to all serious Unix users is to put the exit status
> in the shell prompt.


Alternatively, you can indicate a non-zero exit status by displaying a
prompt symbol in a different colour than usual. This might be preferable
for folks who prefer fixed-width and/or minimalist prompt strings.

For example, my own prompt string

uses a dimmed “λ” in graphical (true colour) environments, and a red “$”
for purely-textual displays like fbdev(4) and wscons(4). It boils down to
something like this:

colour='\033[32m'; # Normal prompt-symbol colour
PS1="\$([ \$? -eq 0 ] && printf '$colour' || printf '\033[31m')\$${colour}"

Basically, if I care about the exit status, I can always run `echo $?`.
Most of the time, I don't (it's enough to know that an error occurred from
the colour alone), so it's not worth cluttering my terminal window with
unnecessary information.

Regards,
— John

On Sun, 5 Feb 2023 at 08:56, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Peter,
>
> At 2023-02-04T16:09:55-0500, Peter Schaffter wrote:
> > The reasoning makes sense but now you have to jump through a hoop
> > when you're using .ab for debugging.  I usually debug with the -z
> > flag.  Formerly,
> >
> >   echo -e ".nr foo 1\n.if r foo .ab\n" | groff -z
> >
> > would helpfully spit out "User abort."  Now there's no way to know
> > whether groff exited cleanly or aborted unless you add a string
> > after .ab.  (A minor annoyance, but I thought I should mention it.)
>
> There _is_ a way... :)
>
> Something I recommend to all serious Unix users is to put the exit
> status in the shell prompt.  I learned this trick early because too many
> times when working interactively, by the time I realize I want to know
> something's exit status, it is too late and $? has been clobbered.
>
> Here's an abbreviated form of my Bash prompt.  I note that the "($?)"
> part is thoroughly portable.  _All_ POSIX, Bourne-, or Korn-descended
> shells should support it.
>
> PS1='\D{%F} \t \s-\v [\l] {\j} ($?) \u@\h:\w !\!\$ '
>
> Regards,
> Branden
>

Re: Inline TTY Pixel Rendering. (Was: groff 1.23.0.rc2 status report)

[John Gardner]

>
> Sounds like it's up John Gardner's alley.  :-)


Actually, I think displaying multimedia within a character-based display is
the second-wankiest thing people have managed to do with their terminal (
Browsh  being the first).

My own prejudices aside, this would be easy to implement in Roff.js if
grotty(1) implements the appropriate device controls. ;-) Also, thanks for
reminding me that I have yet to finish that damn project (or get it to a
point where it's useful for the average *roff user…)


On Mon, 19 Dec 2022 at 19:34, Ralph Corderoy  wrote:

> Hi Branden,
>
> > Probably not a lot of this will be visible to terminal-only users.
>
> Given some TTY emulators now support pixel-level graphics,
> e.g. https://sw.kovidgoyal.net/kitty/graphics-protocol/,
> I have been wondering if anyone is getting man(1) to render to pixels,
> say via PDF, to display inline in the terminal.
>
> Sounds like it's up John Gardner's alley.  :-)
>
> --
> Cheers, Ralph.
>
>

Re: Online Dictionaries. (Was: words (and commands) that I learnt...)

[John Gardner]

>
> Wiktionary […] isn't too hard to edit once you've made one or two changes.
>

I know , don't worry. ;-)

Wiktionary often gives translations, is multi-lingual, though they quite
> rightly put English first :-), and isn't too hard to edit once you've made
> one or two changes.  A DICT server for its content keeps being discussed,
> but there isn't one last time I checked.
>

I'd attribute my preference for Oxford to my innate hatred of Yanklish (U.S
English), but in truth, it's really because OED is bundled with macOS's
Dictionary.app (more proprietary crap, yay!), albeit in one of those
undocumented binary formats

Apple love using in lieu of open-standards. Probably won't stop me from
writing a parser for it some day, though (then I can worry about using it
on OpenBSD, heh.


On Sat, 10 Dec 2022 at 21:00, Ralph Corderoy  wrote:

> Hi John,
>
> > > Your emails are the reason I know and often use dict(1).
> >
> > Branden's e-mails are the reason I consult the Oxford English
> > dictionary
>
> Given the open-source bias of this list's readers, I recommend
> Wiktionary.  I've used dict(1) for a very long time and OED if I'm
> giving a reference for a bug report to fix a British version of English
> dictionary, but I typically enter ‘wikt unix’ into the browser and the
> ‘wikt’ keyword I've created for the site's top-right search box takes me
> to https://en.wiktionary.org/wiki/unix
>
> Wiktionary often gives translations, is multi-lingual, though they quite
> rightly put English first :-), and isn't too hard to edit once you've
> made one or two changes.  A DICT server for its content keeps being
> discussed, but there isn't one last time I checked.
>
> --
> Cheers, Ralph.
>
>

Re: Dynamic Paperlength for PS or PDF device

[John Gardner]

>
> May as well be precise with 21c and 29.7c?


Shit, did I really give A4 in Freedom Units™? My bad.

I'm pinning this on sheet sleep deprivation and football fever. Staying up
to 2:00am AEDT to watch the World Cup, then another at 6:00am—several times
a week—has me running on fumes. I have 4.5 hours of sleep planned before a
5:30am start, because I sure as shit aren't gonna miss England taking on
France. (I swear if France win, I'm gonna cry…)

I'll be wearing my Napalm Death shirt, because it's the closest thing my
wardrobe has to patriotic English attire…)
🏴󠁧󠁢󠁥󠁮󠁧󠁿

On Sat, 10 Dec 2022 at 20:52, Ralph Corderoy  wrote:

> Hi John,
>
> > .\" A4 portrait
> > .pagesize 8.3i 11.7i
> ...
> > .\" A4 landscape
> ...
> > .pagesize 11.7i 8.3i
>
> May as well be precise with 21c and 29.7c?
>
> --
> Cheers, Ralph.
>
>

Re: words (and commands) that I learnt because of Branden

[John Gardner]

>
> Actually, "horde" and "hoard" are homophones


FFS, I keep getting those spellings mixed up. Thank you. :D

On Sat, 10 Dec 2022 at 21:29, Robert Marks  wrote:

> Actually, "horde" and "hoard" are homophones, but one is a noun and the
> other a verb:
> "I use to horde definitions"
>
> Robert Marks, a colleague of John Quiggin's.
>
>
> --
> https://www.agsm.edu.au/bobm 
> 0407665644
>

Re: words (and commands) that I learnt because of Branden (was: preferred /proc//xxx style?)

[John Gardner]

>
>  Your emails are the reason I know and often use dict(1).  Lol.


Branden's e-mails are the reason I consult the Oxford English dictionary
far more often than I'm comfortable admitting. Either I'm learning obscure
words I know I'll never remember when I need them,[1] <#snarky-footnote-1>
or I'm asking myself *"wait, what does *X* mean, again…?"*, chiefly because
I don't read enough (non-technical) literature. :-(

And even when he *isn't* filling my notes file I use to horde definitions
of fancy-sounding words I probably won't ever use, I'm always admiring how
he manages to balance cheeky humour with informative, expressive writing
that brings the Camel Book's writing style to mind (seriously, when
discussing dry topics like typesetting and Unix orthography, a sense of
humour makes digestion *so* much easier).

Also, "*vituperator*" still reigns as my favourite Brandenism[2]
<#if-you-can-read-this-gmail-forgot-to-sanitise-my-fragment-identifier> to
date.

[1] Or awkwardly pigeonhole them into discussions when I do.
[2] An unintentional extension to a reader's vocabulary, often when you
least expect it.
[3] There's no third footnote, I just wanted to point out how infectious
Branden's writing style is.


On Sat, 10 Dec 2022 at 09:10, Deri  wrote:

> On Friday, 9 December 2022 21:09:57 GMT Alejandro Colomar wrote:
> > $ dict deriliction
> > No definitions found for "deriliction", perhaps you mean:
> > gcide:  Dereliction
> > wn:  dereliction
> > moby-thesaurus:  dereliction
> >
> > And yes, dereliction has a definition compatible with your use.
> >
> > Cheers,
> >
> > Alex
>
>
> If deriliction was a word I think it would be unsavoury. :-)
>
> Cheers
>
> Deri
>
>
>
>

Re: Dynamic Paperlength for PS or PDF device

[John Gardner]

>
> so here is my solution:
> the last line of my groff script is:
> ".tm \\n[nl]"
> This shows me the page length in groff units.
> For convenience I put it in a footer macro.


Does this help…?

.de *pagesize* \" $1 = width, $2 = height
\\!x X papersize=\\$1,\\$2
.ll \\$2u-\\n(.o
.pl \\$1
..
.
.\" A4 portrait
.pagesize 8.3i 11.7i
Page 1
.
.\" A4 landscape
.bp
.pagesize 11.7i 8.3i
Page 2

Note that `\!x X papersize=\\n[length],\\n[width]` needs to appear at the *very
beginning* of a new page, before any output has been emitted (hence the use
of .bp in the snippet above).

Hope this helps. :)
— John


On Fri, 9 Dec 2022 at 19:33, Wim Stockman  wrote:

> Hi ,
> Thanks Branden for your answer. but it wasn't really what I was looking
> for.
> I found a solution to set the right page length for each ticket.
> Like Deri said it cuts after each print job but I just needed to tell how
> long each ticket is.
>
> so here is my solution:
> the last line of my groff script is:
> ".tm \\n[nl]"
> This shows me the page length in groff units.
> For convenience I put it in a footer macro.
>
> Then in a bash script I have this:
>
> size=$(groff -P-p6.5c,7c -z kasticket.groff 2>&1)
> size=$(echo "scale=2;$size / 28346 + 0.5" | bc)
> groff -P-p${siz}c,7.2c kasticket.groff > kasticket.ps
>
> The first line gets the size from groff with -z option so no other output
> is given.
> the second converts the units to cm and adds a little bit of margin.
> The last line creates the ticket with the right length.
>
> Kind regards,
> Wim Stockman
>
>
>
> Op vr 9 dec. 2022 om 00:48 schreef Deri :
>
> > On Thursday, 8 December 2022 17:19:49 GMT G. Branden Robinson wrote:
> > > Hi Wim,
> > >
> > > At 2022-12-08T15:51:07+0100, Wim Stockman wrote:
> > > > I am making a simple cash register with a ticket printer.  and I want
> > > > to figure out how I can detect how long my physical paper should be
> > > > without cutting some text off. So I can set it for the device. The
> > > > width is fixed so that is no issue.  Eventually I can run it in some
> > > > loop and detect when it stops having more than one page.
> > >
> > > I reckon I would have a couple of macros that open and close a
> > > diversion, then measure against an argument that specifies the limit
> > > imposed by the hardware (i.e., length of paper roll remaining).
> > >
> > > Here's a conceptual sketch.
> > >
> > > .de StartTicket
> > > .  br
> > > .  di Ticket
> > > ..
> > > .
> > > .de EndTicket
> > > .  di
> > > ..
> > > .
> > > .while 1 \{\
> > > .  StartTicket
> > > .\" input for ticket text goes here
> > > .  EndTicket
> > > .  if (\n[dn] > \n[ticket-printer-paper-length]) \
> > > .ab ticket too long for remaining paper; aborting
> > > .\}
> > >
> > > Please clarify if I've overlooked a requirement.
> > >
> > > Regards,
> > > Branden
> >
> > I'm probably missing something here, but ticket printers are normally
> > continuous rolls with a cutter, so isn't this a problem of controlling
> the
> > cutter rather than specifying a media size. There is usually a printer
> > option
> > to cut after each print job, so if you make each receipt a separate print
> > job,
> > it should do the cutting for you. Just give groff a sufficiently long
> page
> > length for the longest ticket you expect.
> >
> > I have a Brother thermal printer which I use for labels, but it will take
> > a
> > continuous role instead, and I believe it has a proprietary EscP command
> > for
> > controlling the cutting, so there may be a solution using something
> > similar.
> >
> > Cheers
> >
> > Deri
> >
> >
> >
> >
> >
> >
>

Re: Why isn't the device resolution exposed to the formatter?

[John Gardner]

> an *embolus* in my brain

$ echo "embolus" >> ~/Words-that-Branden-taught-me.txt
$ cat $_
inimical, inimicable: harmful; hostile
sesquipedalian: having too many syllables
irascible: easily pissed at shitty UX
indefatigable: incapable of tiring out
internecine: mutually destructive
apodictic: incontrovertible; demonstrably true or certain
vituperate: have a crack at somebody
embolus: an artery blockage

Keep 'em coming. ;-)


On Fri, 18 Nov 2022 at 12:35, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2022-11-18T01:07:23+, Bjarni Ingi Gislason wrote:
> >   The resolution is defined as the number of "units" per 1 inch, so it
> > is "1u/1i", or defined with, for example,
>
> Thanks.  You may notice that after a short time, some caffeine-rich
> blood made it past an embolus in my brain and I realized the same.
>
> https://lists.gnu.org/archive/html/groff/2022-11/msg00117.html
>
> Regards,
> Branden
>

Re: [groff] 15/39: [grog]: Drop relic code and comments.

[John Gardner]

>
> Perl 5.6.1 is incredibly old (April 2001).  I cannot find any evidence of
> any current distribution supporting it.


IIRC, declaring a program version is recommended practice, as future
versions of Perl may have different defaults w.r.t opt-in behaviours like `use
warnings` and `use strict`. The `use v5.6.1;` directive instructs Perl to
assume the defaults for that particular version, ensuring no accidental
breakage.


On Mon, 31 Oct 2022 at 15:42, Dave Kemper  wrote:

> On 10/30/22, G. Branden Robinson  wrote:
> > They'll be told at configure time, because we have an Autoconf test for
> > it.
>
> Reasonable.
>
> > Furthermore, I've rewritten grog nearly completely since Bernd last
> > touched it.  I don't have any idea what Perl 5.6(.1) features Bernd had
> > in mind when he added that statement.
>
> Also reasonable.  I knew grog had been largely rewritten, but didn't
> scrutinize the history closely enough to realize that line was an
> artifact from its old life.
>
> > Perl 5.6.1 is incredibly old (April 2001).  I
> > cannot find any evidence of any current distribution supporting it.
>
> I'm less convinced by this -- unless a difficult roadblock stands in
> the way, I think modern groff ought to work or fail gracefully on an
> obsolete platform -- but the prior two points are convincing enough on
> their own.
>
> > I'd prefer to audit the script as you describe than to restore this
> > arcane feature to it; I had to find out about it the hard way.
>
> Makes sense.  I thought this audit might be onerous, but your patch in
> the followup email doesn't change many lines (and followed pretty
> quickly on the heels of this email).  It looks good to me!
>
>

Re: groff 1.23.0.rc2 readiness

[John Gardner]

>
> As you are the most active developer, would you consider taking over the
> maintainership of groff?
>

Please, please, *please* let that be a "yes"…

On Mon, 22 Aug 2022 at 07:14, Bertrand Garrigues via  wrote:

> Hi Branden,
>
> On Wed, May 25 2022 at 10:56:37 PM, "G. Branden Robinson" <
> g.branden.robin...@gmail.com> wrote:
> [...]
> > Can you do the "git tag 1.23.0.rc2"?
>
> Sorry for my late answer, I have some annoying health issues since June
> (basically a problem in my internal ear that makes me dizzy).  Nothing
> too serious (at least for the moment) but currently I have to somehow
> reduce my time working on a computer.
>
> As you are the most active developer, would you consider taking over the
> maintainership of groff?  Making a release is not too complicated (In
> fact, what took a long time for me was to fill the administrative papers
> and obtain all the access to the various servers and ftp), I'm sure you
> would be able to do it without problems, and you will have a better
> control on the schedule of your dev/changes.
>
>
> Regards,
>
> Bertrand
>
>
>
>

Re: One Page Dungeon Layout in groff?

[John Gardner]

This is what pic(1) 
is for:

# Long version
$ pic < dungeon.roff | troff -Tpdf | gropdf > map.pdf

# Concise version (recommended)
$ groff -p -Tpdf dungeon.roff > map.pdf

If you're new to pic(1), there's a browser-friendly (albeit limited)
reimplementation of the program called Pikchr 
that supports live rendering . Good for
practice, but poor for troff-quality output.

Regards,
— John

On Sat, 13 Aug 2022 at 18:57, Laurens Kils-Hütten  wrote:

> Hello dungeon delving GNU people,
>
> I hope it's fine to write a lengthy request like the following
> as a first post to this list. If not, please be so kind and
> advise me, where I should have asked instead. That said, here
> goes my question:
>
> Yesterday I once more discoverered, how ridiculously fast groff
> is compared to other typesetting toolchains like LaTeX, Python +
> weasyprint or whatever.
>
> Since I enjoy using fast UNIX tools to build some dungeons in my
> spare time, I wonder how much work it'll take to reproduce the
> classic One Page Dungeon layout in groff. Just in case you don't
> know, the layout would simply look like this:
>
> ---
> | ---  Table with  |
> ||   | random  |
> ||  Map of the   | encounters, |
> ||   | various |
> ||Dungeon| general |
> ||   | descriptions|
> || Level | of the level|
> ||   | And finally |
> | ---  a key with  |
> | descriptions of each |
> | individual room of the   |
> | dungeon. Basically it's a|
> | page, with one top-left  |
> | aligned image and text   |
> | floating around the image.   |
> | That shouldn't be too hard.  |
> | Nothing fancy really ... |
> 
>
> The text might extend to the facing uneven page, thus creating a
> two page spread for the level.
>
> Of course I tried what groff seems to deliver out of the box, but
> I find that displays typically use up a page width, or column
> width, with text continuing below the image, but not floating
> around the image like i've shown.
>
> So, any ideas how to do this in groff? Maybe one of the common
> macro packages already supports this kind of layout, only I
> haven't discoverered it, yet?
>
> Thanks in advance,
> cheers,
>
> ~lkh
>
> --
> https://sdf-eu.org/~lkh
>
>

Re: Is it possible to detect `grotty -i` at runtime?

[John Gardner]

>
> `-i` is a _postprocessor_ option here.  Recall the basic *roff pipeline.
>

Ugh, *obviously.* For fuck sake, this is why I shouldn't be allowed to send
e-mails at 4am.

Somehow I got my wires crossed whilst preparing that e-mail, because I
vaguely recall having both grotty(1) and groff(1) open at the same time.
groffy(1), if you will.

Apologies for the retarded e-mail. This hasn't been one of my finer moments.
— J

On Fri, 22 Jul 2022 at 11:09, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2022-07-22T07:29:48+1000, John Gardner wrote:
> > I'm looking for a way to harden my .UL
> > <
> https://github.com/Alhadis/Mono/blob/25765171fbf676b623a4bcbf3d9f93384ef83040/ono.tmac#L171-L233
> >
> > (underline) macro against grotty(1) v1.23's new -i switch,
>
> This command-line option is not forthcoming.  It was introduced in groff
> 1.18 (July 2002).[1]  So it's a 20 year-old feature.
>
> What groff 1.23 does do is add a `-P` option to nroff so that arbitrary
> options can be passed to the postprocessor via that command.[2]
>
> > which causes italicised text to be rendered with actual italics (in
> > TTYs that support SGR 3, at least). My intended workaround involves
> > something like
> >
> > \l'\w,\$1,u\(ul'\h'-\w,\$1,u'\$1
> >
> > or some similarly atrocious hack. Unfortunately, there doesn't appear
> > to be any predefined register to report the status of grotty(1)'s -i
> > and -r switches (both of which change how italic fonts are rendered in
> > the terminal).
> >
> > Can anybody confirm that what I'm seeking to do is even possible?
>
> As I understand *roff architecture, this is indeed impossible.
>
> `-i` is a _postprocessor_ option here.  Recall the basic *roff pipeline.
>
> preprocessor | troff | postprocessor
>
> The most your macro can know about postprocessor-specific information is
> what was given as the -T argument to troff, what's in the corresponding
> `DESC` file (only if a mechanism for exposing that information via the
> roff language has been implemented), and, in groff, what the
> postprocessor-specific macro file (like tty.tmac) chooses to declare.
>
> Further, the pipeline can always be broken up such that a "grout" file
> (the output of the troff command itself) is stored and then processed
> with a different output driver (this is how gxditview works) or with
> different options to the intended output driver.
>
> What are you trying to do?  Avoid underlining text that the output
> device is already underlining itself?
>
> Regards,
> Branden
>
> [1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n1694
> https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n2083
> [2] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n77
>

Is it possible to detect `grotty -i` at runtime?

[John Gardner]

I'm looking for a way to harden my .UL

(underline) macro against grotty(1) v1.23's new -i switch, which causes
italicised text to be rendered with actual italics (in TTYs that support SGR
3, at least). My intended workaround involves something like

\l'\w,\$1,u\(ul'\h'-\w,\$1,u'\$1

or some similarly atrocious hack. Unfortunately, there doesn't appear to be
any predefined register to report the status of grotty(1)'s -i and -r
switches (both of which change how italic fonts are rendered in the
terminal).

Can anybody confirm that what I'm seeking to do is even possible?

— John

Re: Warn on semantic newlines

[John Gardner]

>
> AI is a bane of formatting.


It's getting better.


Though I still prefer smart practices and dumb
 programs,
instead of the other way around.


On Sun, 12 Jun 2022 at 09:01, Douglas McIlroy 
wrote:

> AI is a bane of formatting. When Libre Office sees my name, M. Douglas
> McIlroy, at the beginning of a line, it renders it by default as a
> paragraph numbered with Roman numeral 1000 (and labels the next
> paragraph MI). While groff is not so wild, it does have AI foibles in
> intersentence spacing and in intersymbol spacing in eqn.
>
> To my eye, two spaces between sentences is excessive. So I often set
> the sentence space to zero. The output looks fine; and AI never bites.
>
> Doug
>
>

Re: [TUHS, groff] 1981 edition of AT&T Nroff/Troff User's Manual

[John Gardner]

>
> Since PDF didn't exist in 1981, the document is either a scan or the
> result of a recent *roff run on ancient source.
>

It's most definitely a scan. Magnifying the pages reveals dust, surface
details (grain and creases), and shadow falloff around the holes and edges.
Each page is also titled at slight angles, suggesting manual scanning of
individual pages.

it's an impressive testimonial to the longevity and stability of troff.
>

Absolutely!

On Tue, 7 Jun 2022 at 00:09, Douglas McIlroy 
wrote:

> >
> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf
>
> Since PDF didn't exist in 1981, the document is either a scan or the
> result of a recent *roff run on ancient source. If it was made from
> source, it's an impressive testimonial to the longevity and stability
> of troff. Most probably it's a scan, in which case we owe many thanks
> to the public-spirited person who digitized this trove. Was it you,
> Arnold?
>
> Doug
>
>

Re: Zero Width Space

[John Gardner]

>
> What about "input escape"


Copy+pasta from my earlier post
 to a
concurrent discussion in another thread:

s/input escape/control suppressor/gi
s/input escape/command suppressor/gi

(This discussion appears to have been split between ˜3–4 other threads
, so
I'm unsure which to reply to…)


On Mon, 6 Jun 2022 at 15:55, Ingo Schwarze  wrote:

> Hi,
>
> DJ Chase wrote on Sun, Jun 05, 2022 at 09:57:45PM +:
> > On Sun Jun 5, 2022 at 1:09 PM EDT, Ingo Schwarze wrote:
> >> Richard Morse wrote:
>
> >>> How about "non-breaking escape"
>
> >> That's much too broad since most escape sequences are non-breaking.
>
> >>> or "non-printing escape" (not necessarily in that order of preference)?
>
> >> That's also too broad for my taste; here are a few more escape
> >> sequences that are non-printing and non-breaking unless i'm
> >> missing something: \{ \} \F \f \H \k \M \m \R \S \s \z
> >> The difference between \& and the others is that \& is a no-op
> >> whereas the others all have some side effect.
>
> > What about "input escape",
>
> I wouldn't consider that helpful terminology.
> I would define the term "escape sequence" as "a sequence of
> input characters starting with the escape character, which is the
> backslash by default."  Usually, every escape sequence is intended
> to directly or indirectly affect output, just like any other roff
> input including text lines, requests and macros.  In that sense,
> every escape sequence is both an "input escape" and and "output
> escape": Input and output are merely two complimentary aspects of
> the behaviour of any escape sequence.  Even using \& usually intends
> to influence output, for example suppress end-of-sentence spacing,
> kerning, or ligature building.  So it is hardly more focussed on
> the input side than other escape sequences.
>
> > possibly with a comparing it to the intended
> > purpose of the ASCII escape character?
>
> I dislike that idea, too.  When i consider terminal control codes
> or the use of the escape key in emacs(1) as examples, it seems
> to me that the ASCII escape character compares more readily to
> the roff(7) escape character (by default the backslash) than to
> a complete escape sequence like "\&".  Even if you disregard that
> aspect, the \& escape sequence significantly differs from the
> ASCII escape character in two important aspects: it is often placed
> *after* the thing it is meant to escape rather than before, and
> while the ASCII escape character often gives special meaning to
> ordinary characters, \& does about the opposite: It takes away
> the special meaning that an input character (like '.') intrinsically
> has and turns it into an ordinary character, makes it behave like
> any other character that has no special meaning.
>
> Yours,
>   Ingo
>
>

Re: groff man(7) `B` macro behavior with `\c`, and input traps

[John Gardner]

>
> And to allude to an another conversation we are currently having,
> including those that contain nothing but "\&", but *not* those that are
> completely empty, which would make you think that "\&" is a "zero-width
> non-breaking space" or a "zero-width non-printing character" rather than
> merely an "input break".  But that should really be decided in another
> thread.


I haven't read the entirety of this thread, but why hasn't the name *"command
suppressor"* or *"control suppressor"* been considered? AFAIK, \& has no
other uses outside of an input line (diversions notwithstanding), so naming
it *"input break"* is confusing at best.

Last year I was confused as to why this wasn't working:

.di FOO
\&.BAR
.br
.di
.if '\*[FOO]'.BAR' …

... and it eventually dawned on me that \& was preserved in the diversion,
as opposed to discarded after evaluation. Had the sequence been named *"input
break"* in the documentation, the thought of \& being an opaque character
might never have occurred to me.



On Mon, 6 Jun 2022 at 17:27, Ingo Schwarze  wrote:

> Hi Branden,
>
> G. Branden Robinson wrote on Sun, Jun 05, 2022 at 06:08:46PM -0500:
>
> > [Warning: this message is long.]
>
> Thanks for the thorough explanation.
>
>
> > At 2022-06-05T19:09:53+0200, Ingo Schwarze wrote:
>
> >> On a tangent, i just noticed that
> >>
> >>   .TH TEST 1
> >>   .B foo\c
> >>   bar
> >>
> >> prints "bar" in Roman font with mandoc(1), which seems correct to me,
> >> whereas it appears to print "bar" in bold with groff-current
> >> compiled from git, which seems strange to me, just as if i had
> >> written
> >>
> >>   .TH TEST 1
> >>   .B foo\c
> >>   .B bar
> >>
> >> Which one is correct output, Roman bar or bold bar?
>
> > I believe a bold "bar" is correct.  It is also consistent with Heirloom
> > Doctools nroff, which I last built from its Git HEAD on 2020-02-25.
> > (This is still fairly close to HEAD today.)
> [...]
> > Here is groff man(7)'s definition of the `B` macro from Git HEAD.
> > groff 1.22.4's is not materially different.
> >
> > .\" Set arguments (or next input line if none) in bold style.
> > .de1 B
> > .  itc 1 an-input-trap
>
> Ouch: .itc!
>
> > .  ft B
> > .  if \\n[.$] \&\\$*
> > ..
> >
> > As to _why_ it works this way, here is an attempted explanation and
> > defense thereof.
>
> [...]
> > .B
> > .
> > foo
> >
> > Should "foo" be in bold?
>
> Yes, groff and mandoc output agree.
>
> [...]
> > So, what kind of line produces formatted output?  Well, text lines.
>
> And to allude to an another conversation we are currently having,
> including those that contain nothing but "\&", but *not* those
> that are completely empty, which would make you think that "\&"
> is a "zero-width non-breaking space" or a "zero-width non-printing
> character" rather than merely an "input break".  But that should
> really be decided in another thread.
>
> [...]
> > Today,
> > .B
> > .SM
> > CINCOMPAC
> > confirmed the ceasefire.
> >
> > You could equivalently write this.
> >
> > Today,
> > .B
> > .SM CINCOMPAC
> > confirmed the ceasefire.
>
> Yes, both print CINCOMPAC in bold in both groff and mandoc,
> even though mandoc fails to document that.
>
> [...]
> > .TP
> > .BR \-f [\c
> > .BI = cond\c
> > ]
> > This option frobnicates the boojum,
> > under the condition
> > .I cond,
> > which may be
> > .B florp
> > or
> > .BR snoggle .
>
> Yes, indeed groff and mandoc format this the same way, ending the .TP
> next line scope right before "This option".  In that sense, i understand
> why .TP now uses .itc rather than .it.
>
> [...]
> > And that's the story of why groff and Heirloom Doctools nroff put "bar"
> > in bold.
>
> So since .B uses .itc, and that appears to match Heirloom behaviour
> according to your research, it might be unwise to change that now.
>
> Still, i wonder whether choosing that behaviour was a good decision.
> From the user perspective, this feel asymmetric, in particular for
> users who dislike traps and don't want to think about them:
>
>   .BI command arg\c
>   text
>
> sets "text" in Roman font but
>
>   .I arg\c
>   text
>
> sets "text" in italics?  Isn't that really surprising from the
> user perspective?  No argument about .TP, but wouldn't it have
> been better for .B and .I to use .it rather than .itc for symmetry
> with .BI?
>
> For now, i have added this entry to
> https://cvsweb.bsd.lv/~checkout~/mandoc/TODO?rev=HEAD :
>
>   - the man(7) single-font macros (e.g. .B) use .itc,
> so ".B foo\c" followed by "bar" prints "bar" in bold
> gbranden@ Sun, 5 Jun 2022 18:08:46 -0500
>
> Yours,
>   Ingo
>
>

Re: Setting up repository for user macrosets

[John Gardner]

>
> I was recently thinking of creating one of those "awesome lists" for *roff
> resources. I have quite a few tagged bookmarks to go through..


Naming it awesome-roff and tagging it with the awesome-list
 or awesome
 topics is a great way to get it
recommended to folks by GitHub (in the dashboard sidebar).

 Manually, I presume? I'm not sure how easy / possible it would be to
> automate some / most of that, like in CI/CD.
>

GitHub Actions  to the rescue! Costs
only an internet connection.

On Tue, 31 May 2022 at 00:01, Hendursaga  wrote:

> Hello Hans,
>
> > For a while I've been thinking of creating a github public repository
> with user macrosets for groff.
>
> I was recently thinking of creating one of those "awesome lists" for *roff
> resources. I have quite a few tagged bookmarks to go through..
>
> > I can check if the macrosets produces the expected output before pushing
> to the repo.
>
> Manually, I presume? I'm not sure how easy / possible it would be to
> automate some / most of that, like in CI/CD.
>
> > Would that be a good idea?
>
> I think so! Go for it!
>
> Hendursaga
>
>

Re: groff 1.23.0.rc2 readiness

[John Gardner]

Branden,


> Incidentally there is a bit of a muddle here as your original point in the
> bug report seems to be solely about ~ and ^, whereas Ingo's secondment
> sweeps up the other ASCII characters without identity mappings as well.
>

I'm specifically referring to ~ and ^. Though I agree with Ingo's
sentiments concerning hyphens and directional single-quotes, I consider
those to be in the *"too late to fix"* basket.

Admittedly, I don't understand why ^ and ~ are deserving of special
typesetting treatment. Unlike quotes and dashes, they aren't fundamental
elements of English orthography. I find the wrangling of ^ and ~ to be
equally jarring in PDF output as well; if I were to solicit a change to
Groff's behaviour, it would be suppress the mangling of ^ and ~, forcing
users to request a modifier character specifically if they desire one.

And probably 95% or more of groff users are doing so via a package of some
> sort prepared by a distribution vendor like Debian GNU/Linux, OpenBSD,
> Fedora, or some other intermediary between "upstream" (us) and themselves.
>
> That is why I said "If every *nix vendor in the world seizes upon the
> above and adds it, I can view it with equanimity."


Who's to say every intermediary will share the same opinion about tampering
with man.local? Homebrew <https://brew.sh/>, for example, has a strict
policy about patching <https://docs.brew.sh/Formula-Cookbook#patches>
software, meaning there's zero chance of your suggested amendment reaching
macOS users.

I don't think man pages should have to be written one way for terminals and
> another for PDF
>

I wholeheartedly agree, which is why I believe we should abolish the hell
out of Groff's “special” treatment of ^ and ~. They don't appear frequently
enough in Latin-based writing systems to justify an exception to Groff's
character handling rules (whereas dashes and directional quotes do)

"grout" is my shorthand for "device-independent output produced by GNU
> troff"
>

I've given in and taken to calling it "ditroff" informally, even though I
know damn well that it's a misappropriation.

> .
>

On Sat, 28 May 2022 at 08:51, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Johm,
>
> At 2022-05-27T11:04:52+1000, John Gardner wrote:
> > > I have no problem adding an item to the PROBLEMS file with a chunk
> > > of groff source that people can put in their site "man.local" or
> > > "troffrc" files to achieve the ASCII-degradation of the five glyphs
> > > that novice man page writers abuse so copiously.
> >
> > Can we *please* be practical about this?
>
> I'm trying to be.
>
> Incidentally there is a bit of a muddle here as your original point in
> the bug report seems to be solely about ~ and ^, whereas Ingo's
> secondment sweeps up the other ASCII characters without identity
> mappings as well.
>
> > 90% of Groff users, if not more, are only doing so via man(1) to read
> > man pages.
>
> Yes.  And probably 95% or more of groff users are doing so via a
> package of some sort prepared by a distribution vendor like Debian
> GNU/Linux, OpenBSD, Fedora, or some other intermediary between
> "upstream" (us) and themselves.
>
> That is why I said "If every *nix vendor in the world seizes upon the
> above and adds it, I can view it with equanimity."[1]
>
> > Many of whom are probably oblivious to the existence of a typesetting
> > system underneath that's powering it all. They won't care about local
> > configuration, they'll just be annoyed that there's another bunch of
> > annoying characters they need to replace in anything copy+pasted from
> > a terminal. Think Stack Overflow posts containing ˆ and ˜ by hapless
> > users unaware that a regex or path they just copied contain what're
> > essentially diacritics without a character.
>
> True; people will attempt copy and paste from PDF files as well.  That's
> why I want to prevail upon man page authors to choose correct glyphs in
> their documents--so we can get a consistent experience on all output
> devices.  I discussed this with Michael Kerrisk, the co-maintainer of
> the Linux man-pages project (Alejandro's counterpart) almost a year and
> a half ago[2].  He's been doing that job a long time and was not
> alarmed.
>
> > Which reminds me: *these characters were designed to be overstruck*. A
> > + ˆ = Â, A + ˜ = Ã.
>
> In ASCII?  Yes, except for the hyphen, originally they were--if they
> weren't replaced by some national character set's alternative glyphs.
> This 

Re: groff 1.23.0.rc2 readiness

[John Gardner]

>
> I have no problem adding an item to the PROBLEMS file with a chunk of
> groff source that people can put in their site "man.local" or "troffrc"
> files to achieve the ASCII-degradation of the five glyphs that novice man
> page writers abuse so copiously.


Can we *please* be practical about this?

90% of Groff users, if not more, are only doing so via man(1) to read man
pages. Many of whom are probably oblivious to the existence of a
typesetting system underneath that's powering it all. They won't care about
local configuration, they'll just be annoyed that there's another bunch of
annoying characters they need to replace in anything copy+pasted from a
terminal. Think Stack Overflow posts containing ˆ and ˜ by hapless users
unaware that a regex or path they just copied contain what're essentially
diacritics without a character.

Which reminds me: *these characters were designed to be overstruck*. A + ˆ
= Â, A + ˜ = Ã. In a PDF or PostScript document, or with a hardware
teletype, this sort of composition is easy. In a modern terminal
environment, not so much. They're not making typesetting any better,
they're only making user experience worse.

Now, we can deplore the state of man page authorship as much as we like,
but the truth is that most software authors won't see this as a problem on
their end, or with end user configuration. They'll see this as a regression
in the latest version of Groff and will file bug reports accordingly.

If you still decide to go ahead: Don't say I didn't warn you.

On Fri, 27 May 2022 at 01:23, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2022-05-27T00:38:31+1000, John Gardner wrote:
> > Please consider #62494 <https://savannah.gnu.org/bugs/?62494> ASAP.
>
> I'm afraid I have to say I _have_ considered it; I just haven't mustered
> the energy to write a message pushing back on you and Ingo about it yet.
>
> So, here's Mean Mr. Mustard.
>
> Anybody who's read the previous discussion(s) we've had on this list
> about it, or the current version of the groff_char(7) man page, will be
> aware of my objections (the latter because I think those objections
> follow from a historical understanding of troff special characters).
>
> > Otherwise, it's going to piss a lot of users off.
>
> I have no problem adding an item to the PROBLEMS file with a chunk of
> groff source that people can put in their site "man.local" or "troffrc"
> files to achieve the ASCII-degradation of the five glyphs that novice
> man page writers abuse so copiously.
>
> I don't think man pages should have to be written one way for terminals
> and another for PDF, whence goes the road you and Ingo are walking.  It
> is therefore important to make these ASCII-degradations contingent on
> (1) usage of the man(7) package and (2) output to the 'utf8' device.
>
> If it were to go in man.local, it would look something like this.
>
> .if '\*[.T]'utf8' \{\
> .  char ' \[aq]
> .  char - \-
> .  char ^ \[ha]
> .  char ` \[ga]
> .  char ~ \[ti]
> .\}
>
> Is the foregoing enough to satisfy anyone?
>
> If every *nix vendor in the world seizes upon the above and adds it, I
> can view it with equanimity.  We can at best model correct behavior in
> our own distribution.  I expect I'll have to spend some effort writing
> patches against several man(7)-generation tools, some of which are
> probably utterly stagnant, unmaintained, and unreceptive, and the output
> of which man page writers who don't read any of _our_ documentation draw
> upon for imitation.  I harbor no illusion that achieving correct glyph
> usage will not be a long road.
>
> Quixotically yours,
> Branden
>

Re: groff 1.23.0.rc2 readiness

[John Gardner]

Hi Branden,

I'm running out of things I can think of to do before RC2.
>

Please consider #62494  ASAP.
Otherwise, it's going to piss a lot of users off.

Regards,
— J

On Thu, 26 May 2022 at 13:56, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Bertrand,
>
> I'm running out of things I can think of to do before RC2.
>
> Below, I'll excerpt the FOR-RELEASE file and annotate it.
>
> * Increment the version number.  groff requires an explicit three-part
>   version, major.minor.revision, due to the .Y register.
>
> Can you do the "git tag 1.23.0.rc2"?  As I understand it, that is all
> that is required for this step.  (Maybe I should move it to be later in
> the file.)
>
> * Update font description files that we generate from external data and
>   provide with our source distribution.
>
> Directory  Format  Tool
> -  --  
> devX*  X11 core/server fontxtotroff
>
>   The make(1) target "maintainer-font-descriptions" produces these font
>   descriptions.
>
> This was "done" after this following commit, but it caused no changes to
> in-tree files.
>
> commit 3c82cbbfe5c378f8fc274b93cce28624b19a1b8a
> Author: G. Branden Robinson 
> Date:   Sun Feb 27 21:18:19 2022 +1100
>
> * Retrieve current versions of UnicodeData.txt[1] and the Adobe Glyph
>   List (AGL)[2], and use them with
>   src/utils/afmtodit/make-afmtodit-tables to update
>   src/utils/afmtodit/afmtodit.tables.
>
>   [1] E.g., .
>   Check for the latest _released_ version of Unicode at the time.
>   Data for the forthcoming release may be available.
>   [2]    glyphlist.txt>
>
> commit f04365c2b33e0d031e509bc4e739eaf3b28b3af0
> Author: G. Branden Robinson 
> Date:   Wed May 25 21:13:35 2022 -0500
>
> * Update the 'gnulib' sub-module to the latest version and the
>   corresponding required commit hash identifier in 'INSTALL.REPO'.
>
> commit f55d8f418935e4f63f2a54ea2fa99e25b42767f8
> Author: Bertrand Garrigues 
> Date:   Sat Apr 23 17:50:07 2022 +0200
>
> * Update the release version number where it is hard-coded.
>   + NEWS
>   + BUG-REPORT
>   + arch/mingw/grap2graph.cmd
>   + doc/groff.texi (multiple occurrences)
>   + doc/webpage.ms
>
> commit 5224da3e11cf586c02239b963e724425e5de4689
> Author: G. Branden Robinson 
> Date:   Sun Oct 25 14:18:09 2020 +1100
>
> * If the major or minor version number is being incremented, split off
>   a historical ChangeLog file.
>
> commit c11995df168e38d4d6dddf11c163951a15104f34
> Author: G. Branden Robinson 
> Date:   Fri Feb 19 08:22:07 2021 +1100
>
> * Update in 'src/roff/groff/groff.cpp' the 'printf' that displays the
>   copyright.
>
> commit e70b435374060d0e8a7de115899193fadecc9d3f
> Author: G. Branden Robinson 
> Date:   Wed May 25 21:36:51 2022 -0500
>
> * Update the copyright year with 'update-copyright.sh'.
>
> I haven't done this yet; I'm a little uneasy with the practice, and in
> the past it has been error-prone so I'm apprehensive about doing it.  I
> try to update copyright years by hand when I make a change to a file
> that I think of as being substantive enough to constitute "original
> expression", but that is of course a highly subjective standard.
> Regardless, even if the script isn't run, we still won't have many if
> any truly stale dates.  Can you do this one too, if you think it's
> warranted?
>
> 
>
> I think an announcement email for RC2 should include the portion of the
> 'NEWS' file up to the last release.  Alternatively, if you'd like to
> excerpt the items you consider most noteworthy, that would be fine too.
>
> I have several ideas for release notes which would similarly excerpt
> 'NEWS' and include some statistical information on commits,
> contributors, and resolved Savannah tickets (inspired by other
> announcements I've seen on the info-gnu list), but I don't want to gate
> the RC on that.  I can work on it while feedback on RC2 comes in.
>
> Our RC1 announcement[1] included building instructions.  I've updated
> (and in the first 2 cases, created) all of the following top-level
> documentation files recently.
>
> FOR-RELEASE
> HACKING
> INSTALL.REPO
> INSTALL.extra
> LICENSES
> NEWS
> PROBLEMS
> README
>
> Of particular interest for an RC are the updated building instructions.
> As part of that I've documented how to build from the snapshot archives
> that Savannah/cgit create on demand from any commit.
>
> I should also note that Bjarni suggested that we CC the GNU
> platform-testers list on our future beta/RC announcements[2].  If you
> like this idea and it works out, I can add this step to "FOR-RELEASE".
>
> If ther

Re: A Modern Typesetting Language. (Was: .TQ to replace .PD 0)

[John Gardner]

Hi Ralph,

Or at best, gives it through some clunky ‘treat it as a string’ mechanism.
>

How is that clunky? Text is text. It's opaque, honest, and universal. The
foundation of the Unix Philosophy… you know this as well as I do. ;-)

One could look at shoehorning evermore complexity through to the
> post-processor, but that denies integration with the rest of troff of the
> expressiveness of those features.
>

I have a (currently hypothetical and unimplemented) solution that might
resolve the issue of integration and expressiveness. I've posted about it
before in this list
 and won't
subject folks to another long-winded diatribe. ;-) But the premise is that
this:

.UR https://example.com/
Hyperlink example
.UE .

gets preprocessed into something this:

\X'meta: begin link'\c
.UR \X'meta: begin href'https://example.com/\X'meta: end href'
Hyperlink example
.UE .
\X'meta: end link'

… that's then used to demarcate regions of semantic or structural value for
a postprocessor that enhances the groff_out(5) source in some
driver-specific fashion.

I'm cognisant of the challenges this would involve, and I'm not even
claiming it's doable at this stage, but I'd still like to have a crack at
it nonetheless. 👍 It'll be fun when I get around to it.

— John

On Wed, 25 May 2022 at 21:43, Ralph Corderoy  wrote:

> Hi John,
>
> > > Support of modern font technologies and of course languages which
> > > aren't left-to-right.
> >
> > Agreed.  But for everything else you've mentioned: it's just a matter
> > of writing another PDF postprocessor (or some other adapter for a
> > particular format).  Postprocessors are where the real beauty of
> > Troff's staying power shines.
>
> One could look at shoehorning evermore complexity through to the
> post-processor, but that denies integration with the rest of troff of
> the expressiveness of those features.  Or at best, gives it through some
> clunky ‘treat it as a string’ mechanism.  Think more of a language were
> expressions can have these as first-class things with powerful
> operators.
>
> > > but the modern graphics model of PDF has moved on a lot from theirs
> > > and isn't targeted. Images and SVG as first-class objects.
> > > Transformation matrices. Advanced colour handling.  Text-flow
> > > layout.
> >
> > PDF's graphics model hasn't changed
>
> From memory, PDF 1.3 added transitioning between colours, PDF 1.4
> introduced transparency, and PDF 1.7 gave us 3D artwork.  There must be
> many more incremental improvements.  :-)
>
> > and SVG isn't a first class object in PDF documents.
>
> No, I know.  I was meaning they would be in a new document-layout
> language.
>
> --
> Cheers, Ralph.
>
>

Re: .TQ to replace .PD 0

[John Gardner]

Hi Ralph,

> Support of modern font technologies and of course languages which aren't
left-to-right.

Agreed. But for everything else you've mentioned: it's just a matter of
writing another PDF postprocessor (or some other adapter for a particular
format). Postprocessors are where the real beauty of Troff's staying power
shines.

> but the modern graphics model of PDF has moved on a lot from theirs and
isn't targeted. Images and SVG as first-class objects.  Transformation
matrices. Advanced colour handling.  Text-flow layout.

PDF's graphics model hasn't changed, and SVG isn't a first class object in
PDF documents. Are you conflating it with web browsers and HTML/CSS?
Because that's a completely different beast to PDF…


On Wed, 25 May 2022 at 21:13, Ralph Corderoy  wrote:

> Hi Igno,
>
> > We actually do have partial control over a significant portion of
> > existing manual pages, by virtue of some relevant people participating
> > in the list .
> ...
> > Admittedly and for good reasons, huge numbers of individual, portable
> > software packages also provide manual pages, and we have no direct
> > access to the developers of those.  Then again, when those people
>
> I take your point, but I think your outlook is biased to the
> free-software operating systems.  In addition to the man pages of the
> many individual projects, which you acknowledged, there's also the
> commercial OS like AIX.  Not forgetting Humm's Plan 9.  :-)
>
> > Regarding new text formatters and markup languages, i don't see much
> > need for them.  Over the decades, most other attempts turned out much
> > worse than ROFF and LaTeX, including practically all that are
> > significantly younger
>
> I agree if it were just to be another troff or Lout, but the modern
> graphics model of PDF has moved on a lot from theirs and isn't targeted.
> Images and SVG as first-class objects.  Transformation matrices.
> Advanced colour handling.  Text-flow layout.  Support of modern font
> technologies and of course languages which aren't left-to-right.  More
> DTP like https://www.scribus.net than academic paper.  There's lots of
> experimentation which could be done to see if a textual language which
> allowed straightforward text entry would have use with today's printing.
>
> Sometimes it's right to start from scratch and to allow much more
> breaking change as different approaches are tried.  Again, we're back to
> Plan 9.
>
> --
> Cheers, Ralph.
>
>

Re: traveling for a few days

[John Gardner]

Hi Bertrand,

Yes please open a ticket, I'll try to have a look,
>

It's done. See #62357 <https://savannah.gnu.org/bugs/index.php?62357>.

I've left my build directory untouched, so if you need me to attach another
artefact or log-file, please let me know.
— John


On Sun, 24 Apr 2022 at 20:15, Bertrand Garrigues <
bertrand.garrig...@laposte.net> wrote:

> Hi John,
>
> On Sun, Apr 24 2022 at 04:39:57 AM, John Gardner 
> wrote:
> > On macOS, Groff builds and installs perfectly from a fresh checkout
> (currently using
> > f55d8f41).
> >
> > However, running `make check` produced 6 failing tests:
> [...]
> > I've saved the build log and test-suite.log. Should I open a ticket on
> Savannah?
>
> Yes please open a ticket, I'll try to have a look,
>
> Regards,
>
> Bertrand
>

Re: traveling for a few days

[John Gardner]

On macOS, Groff builds and installs perfectly from a fresh checkout
(currently using f55d8f41).

However, running `make check` produced 6 failing tests:

FAIL: src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh
> XFAIL: src/roff/groff/tests/string_case_xform_unicode_escape.sh
> XFAIL src/roff/groff/tests/string_case_xform_unicode_escape.sh (exit
> status: 1)
> XFAIL: tmac/tests/an-ext_ME-punct-hyphenates.sh
> XFAIL tmac/tests/an-ext_ME-punct-hyphenates.sh (exit status: 1)
> XFAIL: tmac/tests/an-ext_UE-breaks-before-long-URIs.sh
> XFAIL tmac/tests/an-ext_UE-breaks-before-long-URIs.sh (exit status: 1)
> XFAIL: tmac/tests/an-ext_UE-punct-hyphenates.sh
> XFAIL tmac/tests/an-ext_UE-punct-hyphenates.sh (exit status: 1)
> XFAIL: tmac/tests/e_footnotes-work-with-columns.sh
> XFAIL tmac/tests/e_footnotes-work-with-columns.sh (exit status: 1)
>

The first failure bothers me the most, as it relates to something I've
noticed Groff doing for a while now:

FAIL: src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh
> ==
>
> checking "ascii" output device...group1 group2 group3 " \ ` ' - ^ ~
> checking "latin1" output device...group1 group2 group3 " \ ` ' - ^ ~
> checking "utf8" output device...group1 group2 group3 " \ ' FAILED ` FAILED
> - FAILED ^ FAILED ~ FAILED
> FAIL src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh (exit
> status: 1)


I've saved the build log and test-suite.log. Should I open a ticket on
Savannah?

in the event I should be eaten by a grue and don't return.  :P
>

Carry some illuminate with you, and for God's sake, keep the damn light on.

— John



On Sun, 24 Apr 2022 at 02:38, Branden Robinson 
wrote:

> Hi Bertrand,
>
> Excellent to see you back!  Please excuse the GMail-compromised response,
> but I wanted to venture a guess about the test failures you're seeing, in
> hopes I can hasten the problem toward resolution.
>
>
> On Sat, Apr 23, 2022, 11:10 Bertrand Garrigues <
> bertrand.garrig...@laposte.net> wrote:
>
> > Hi Branden,
> >
> > On Fri, Apr 22 2022 at 01:30:54 AM, "G. Branden Robinson" <
> > g.branden.robin...@gmail.com> wrote:
> > > Hi folks,
> > >
> > > Just wanted to advise that I'll be traveling for a few days so my usual
> > > periodic burst of commits to groff Git's repo will be delayed.
> > >
> > > I'm attaching the work that I have pending, in the event I should be
> > > eaten by a grue and don't return.  :P  It's just a snapshot; usually
> > > these things see some rebasing and modification before a real push.
> > >
> > > These are all/mostly documentation fix-ups; when I return I want to
> > > continue the build tidying process as the slog toward 1.23.0.rc2
> > > continues.
> >
> > I had a little bit of time to test; I see 3 fails (I'm testing on
> > Archlinux) that block the release:
> >
> >FAIL: tmac/tests/e_chapter-titles-work.sh
> >FAIL: tmac/tests/e_ld-works.sh
> >FAIL: tmac/tests/localization-works.sh
> >
> > For the 1st one we try to do:
> >
> >   grep -Fqx '$C: "Chapter" "1" "The Boy Sickens"'
> >
> > however the output I have is:
> >
> >$C: \$@ $C: \$@ $C: \$@ Chapter 1 The Boy Sickens Chapter 2 The Boy
> > Dies Appendix A Pathology of Boy Aged 11 Years
> >
> > I haven't checked the 2 other ones yet.
> >
>
> Something all 3 of these tests have in common is that they populate a shell
> variable with embedded multiple backslashes, then pass that variable
> (double-quoted) as an argument to 'echo'.
>
> It might be necessary to use printf(1) here instead.
>
> > Probably need to bite the bullet and update the gnulib submodule to
> > > something relatively current.  Bjarni has I think already tried this;
> if
> > > someone else would like to give it a spin, too, I'd appreciate it.
> >
> > I've updated the gnulib to their latest sha and updated our bootstrap
> > script, no issue, so it's on master now.
> >
>
> Thank you!
>
> Regards,
> Branden (without ready access to his GPG key)
>

Re: Question on hyperlinks in groff

[John Gardner]

Hi Chems,

When reading the s.tmac file, specifically the description for the .[
> macro, it mentions a macro called .#, but I can't find its definition
> anywhere.
>

Both the .[ and .# macros belong to the Mono package
. This is a project of mine (i.e., not
part of Groff) although it currently doesn't support DVI hyperlinks. In
fact, I wasn't aware DVI even supported interactivity (then again, my
knowledge of anything TeX-related is less than rudimentary).

Please be aware that the .[ macro in particular is largely unfinished, and
there are lots of rough edges I still haven't smoothed out.

Regards,
— John

On Sat, 26 Mar 2022 at 04:04, Chems Eddine Naimi 
wrote:

> Hello everyone,
>
> I'm pretty new to groff, and I've been playing with the tmac files,
> writing my own macros and all. Now I'm trying to implement internal links
> in dvi documents.
>
> When reading the s.tmac file, specifically the description for the .[
> macro, it mentions a macro called .#, but I can't find its definition
> anywhere. I tried greping the whole directory but to no avail. Here's the
> passage I'm talking about :
> .\" Examples:
> .\" .[ eBay ]( https://ebay.com )
> .\" .[ Contact ]< cont...@author.com >
> .\" .[ Term ][ term-id ] *\" See .#*
> External links to sites and e-mails work fine, but I can't find a way to
> declare any term-id for use in internal links.
>
> Thank you in advance for your help,
> Chems.
>

Re: [BUG] groff: inconsistent behavior of " to separate arguments

[John Gardner]

> GMail did the exact same thing to me with the same 3 emails from Ingo.
> His messages since then _seem_ to have gotten to me reliably.

I recently had to add a Gmail filter to mark e-mails from Ingo as *NOT*
spam. He e-mailed me again recently and I nearly missed it under the usual
deluge of bullcrap my spam folder is routinely subjected to.

Since Gmail's *"Report as not-spam"* function appears to be doing fuck all,
I recommend every other Gmail user do something similar to this:

Matches: from:(schwa...@usta.de)
Do this: Never send it to Spam, Mark it as important

Total pain-in-the-arse.

On Fri, 25 Mar 2022 at 15:17, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2022-03-20T19:25:30+0100, Alejandro Colomar (man-pages) wrote:
> > Hi Ingo,
> >
> > On 3/20/22 10:48, Ingo Schwarze wrote:
> > > Hi Alex,
> > It seems your emails didn't reach me directly.
> > But the email from the mailing list arrived to my other mailbox.
> > Hummm.
> >
> > After that, I checked again, and I found your email in the SPAM folder...
> > #$%* gmail!
>
> GMail did the exact same thing to me with the same 3 emails from Ingo.
> His messages since then _seem_ to have gotten to me reliably.
>
> Move fast, break stuff.  You're not the customer, you're the product.
> Enjoy the feel of our FAANGs in your neck.
>
> Regards,
> Branden
>

Re: Five glyphs: a minor PostScript challenge

[John Gardner]

>
> Does anyone have enough PostScript wizardry to achieve any of this?


I do. I'm quite  fluent
 in PostScript programming, and your
suspicions about the dynamic glyph generation are correct.

I'll have a more serious look into this tomorrow when I'm not about to
collapse under my insomnia.

On Tue, 15 Mar 2022 at 23:29, Damian McGuckin  wrote:

> On Tue, 15 Mar 2022, G. Branden Robinson wrote:
>
> > A. \[-+]: The minus-plus.  We should be able to dynamically generate
> >   this from \[+-] by reflecting the latter about a horizontal axis.  If
> >   the glyph is flipped within its bounding box, I guess the result
> >   would need to be vertically shifted to align it on the baseline.
>
> This needs a lot of work but might get you started.
>
> \s+1\fB+\h'-0.55m'\v'-0.30v'\-\v'+0.30v'\fP\s-1
>
> > Does anyone have enough PostScript wizardry to achieve any of this?
>
> What I had has long disappeared from my brain. It is 20 years ago.
>
> Stay safe - Damian
>
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted
> here
> Views & opinions here are mine and not those of any past or present
> employer
>
>

Re: Groff hanging when called from Java

[John Gardner]

Are you sure the process isn't waiting for input from an interactive
(TTY-attached) STDIN stream?

Try sending ^D (CTRL+D), which should tell it that it's reached EOF. I
don't know much about Java, only that it's weird and gross (so I have to
assume writing to /dev/stderr or even /dev/console doesn't work as
expected...)

On Sat, 18 Dec 2021, 1:10 am Blake McBride,  wrote:

> Greetings,
>
> I have been calling groff from java for a long time.  Works well.  However,
> recently I passed an errant file to groff through java and the process is
> hanging.  When run from the command line it works as expected.  But when I
> run it through java it hangs.  I'm at a loss.  Any help would sure be
> appreciated.
>
> The Java code (Main.java):
>
> public class Main {
>
> public static void main(String [] argv) throws Exception {
> ProcessBuilder builder = new ProcessBuilder("groff", "-mm", "-t",
> "-Tpdf", "file.mm");
> Process p = builder.start();
> p.waitFor();
> System.out.println("Done.");
> }
> }
>
>
> It hangs on the p.waitFor().  If I do a "ps lax |grep groff" I see groff is
> still running (hung).
>
> I am attaching file.mm  I know it is wrong, but it shouldn't cause a hang.
>
> Sure appreciate any help!
>
> Blake McBride
>

Re: Should vertical motions be in vees or ems? Where does the baseline go?

[John Gardner]

>
> The 'w' prefix is interestingly misleading, since there's no word
> separation. Is this a cat2dit bug?


Not a bug, but a hack on my part. See, Roff.js (currently) relies on `w`
instructions to tell when a word has finished being printed, something
which is necessary because of the way it buffers characters in memory (to
avoid the jarring gaps resulting from the system's font metrics differing
ever-so-slightly from those used by Groff's output driver; this becomes
especially visible in long-running spans of text).

The C/A/T didn't *have* an instruction for indicating a word-break (nor
would having one make much sense, as this instruction is purely
informational in nature). Hence, you can safely ignore those `w` additions.
;-)

I had no luck pasting this into John's web-demo viewer, possibly because
> it's expecting output for the 'pdf' device as it explicitly claims.
>

I added a -T option to cat2dit(1) for this very reason. Try this:

/path/to/cat2dit -Tpdf < cat.out


On Tue, 23 Nov 2021, 8:51 pm G. Branden Robinson, <
g.branden.robin...@gmail.com> wrote:

> At 2021-11-22T23:06:38-0500, Douglas McIlroy wrote:
> > > This [disagreement in position of a drawn baseline]
> > > seems like a bug in Heirloom Doctools troff to me, but given that
> > > code base's provenance, it's easily possible that it's better aligned
> > > with AT&T troff behavior.  (Does someone know?)
> >
> > I don't know absolutely, but it's very likely that both groff and
> > heirloom agree with one "AT&T troff'' or another.
>
> I would not be at all surprised.  I earlier compared certain attitudes
> to that of fundamentalist evangelicalism.  A lot of people who tout the
> Bible at you get frustrated when you ask whether they mean the King
> James or the New International Version or whatever.  With AT&T troff,
> there's more than one authoritiative source to cite, and as with most
> topics of nontrivial complexity, these sources sometimes conflict.
>
> > Ossanna's original did not have drawing capability, so it created
> > horizontal lines as a row of underscores. The vertical position and
> > thickness of such a line is determined by the current font. Later, in
> > ditroff, Kernighan introduced \D drawing capability. Then the position
> > and thickness of the line became the baseline and the current point
> > size.
>
> With some swift cleanup work, John Gardner got cat2dit working for me,
> and the results are interesting.  I won't say that they're more than
> suggestive, because (1) we don't know that cat2dit itself is flawless,
> and (2) there is more I need to understand, I'm sure.  But as a
> translation of V7 Unix troff output into something modern eyes can read
> (after absorbing groff_out(5) or similar), it's valuable.
>
> An exegesis of cat2dit(1) output from an early version of my vertical
> movement demo follows.  Those likely to be bored are advised to bail out
> now.
>
> First, the input.
>
> .sp 2v
> \l'\n(.lu'\h'|0'
> Ofoo\dbar\rbaz\dqux
> foo\dbar\u\ubaz\dqux
> foo\v'0.5v'bar\v'-1v'baz\dqux
> foo\v'0.5m'bar\v'-1m'baz\dqux
>
> Now, the C/A/T output translated to device-independent troff.
>
> x T cat
> x res 432 1 3
> x init
>
> I had no luck pasting this into John's web-demo viewer, possibly because
> it's expecting output for the 'pdf' device as it explicitly claims.
>
> p1
> x font 1 R
> x font 2 I
> x font 3 B
> x font 4 S
> f1
> s10
>
> So far this looks highly idiomatic.
>
> v31
> v31
> v10
> h127
> h127
> h127
>
> I think we see the legacy of signed char use for storage of magnitudes
> here, though why vertical magnitudes are more limited that horizontal
> ones is a curious post.
>
> h35
> Cul
> wh18
>
> The first chunk of horizontal rule is rendered exactly as Doug said,
> with a 'ul' special character.
>
> Cul
> wh30
>
> The foregoing is repeated many times.  The 'w' prefix is interestingly
> misleading, since there's no word separation.  Is this a cat2dit bug?
>
> wh-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-127
> h-12

Re: No rule to make target `tmac/mdoc/doc-common', needed by `all-am'. Stop.

[John Gardner]

Hi Axel,

Before running ./bootstrap from the root directory, make sure *all *build
artefacts are wiped:

git pull && git checkout -- . && git clean -xfd

I recall seeing this exact error a while ago when attempting to recompile
Groff. It might be related.


On Fri, 29 Oct 2021 at 05:18, Axel Kielhorn  wrote:

> Today I did a
>
> make clean
> ./configure --with-uchardet=no
> make
>
> and got
>
> make[1]: *** No rule to make target `tmac/mdoc/doc-common', needed by
> `all-am'.  Stop.
>
> Yes, I did an
>
> autoconf
>
> and
>
> autoupdate
>
> since autoconf (GNU Autoconf) 2.71f
>
> suggested that.
>
> Today I’m on MacOS 10.13 with a current Macports installation for the
> auto* tools.
>
> Greetings
>
> Axel
>
>
>

Re: Portability to Mac OS X (was: Sed failure in contrib/sboxes on MacOS)

[John Gardner]

>
> https://mandoc.bsd.lv/texi2mdoc/


I was thinking of ms(7) more than manual pages, actually. Think single-page
HTML output.

mdoc(7) is too restrictive and specialised to lend itself well to the
various applications Texinfo manuals are used for.

(Anyway, I was just spitballing. I want an excuse to separate Groff from
the TeX world as much as humanly possible…)


On Fri, 29 Oct 2021 at 04:27, John Gardner  wrote:

> In lieu of escaped newlines and awkward sed(1) formatting, you can use
> the following line to insert an empty line:
>
> /^Before$/ { N; s/\n/&&/; }
>
> Note that BSD sed(1) is picky about braces and semicolons.
>
>  I have groff building successfully on Mac OS X now.
>>
>
> I recently upgraded to macOS 12.0.1 (Monterey), though I've not recompiled
> Groff yet. Gonna do that now and report on any new issues.
>
> However, it should be possible to make generated *.info files part of
>> the distribution archive and thereby reduce the dependency load for
>> people who _don't_ care about running "make doc" (which demands an
>> entire working TeX installation).
>>
>
> Even better: a preprocessor to convert Texinfo markup to Roff source
> (possibly targeting a macro package). I've said it before, and I'll said it
> again: Groff needs TeX about as badly as it needs an Instagram page.
>
> texi2roff(1) anyone? (I imagine it'd be fun to write in Perl…)
>
> On Wed, 27 Oct 2021 at 16:10, G. Branden Robinson <
> g.branden.robin...@gmail.com> wrote:
>
>> Hi, Andreas!
>>
>> At 2021-10-27T00:07:22+0200, Andreas Kusalananda Kähäri wrote:
>> > Actually, that only makes it work with OpenBSD sed and GNU sed.  It
>> > still fails with
>> >
>> >   sed: Unrecognized command: .lf 1 doc/webpage.ms
>> >
>> > when using Plan 9 sed.  Not tested with macOS.
>> >
>> > So it looks like the best bet is to insert a literal newline somehow,
>> > after the \ like the Makefile *tries* to do.  How to do that properly
>> > is unfortunately beyond me as I don't grock Make quoting rules very
>> > well.
>>
>> It's a pretty rigid constraint problem.  The GNU Autoconf manual has a
>> canned solution that I was able to adapt easily[1].
>>
>> I have groff building successfully on Mac OS X now.
>>
>> However, I see more work ahead of me.
>>
>> 1. There are 8 test failures.  These are probably portability failures
>>in my scripts.
>>
>> 2. I want to check out a couple of compiler warnings.
>>
>> 3. The linker warnings I mentioned earlier on this list may be a
>>long-standing LLVM issue with no resolution in sight.[2]  I don't
>>intend to act on this unless someone with relevant expertise can
>>advise me.  I hope the Homebrew folks know whether this is a real
>>problem and if so, how to get around it.
>>
>> 4. afmtodit produces a lot more warnings on recent URW fonts than it
>>does on my Debian buster system.[3]
>>
>> 5. pnmcrop is spewing warnings[4] and possibly we're getting blank
>>images in pic.html and webpage.html as a result.  If a workaround
>>cannot be found, I guess this means that yet another new Autoconf
>>test that warns users of broken tooling is necessary.  :/
>>
>> 6. Some time ago I bumped our minimum required Texinfo version to 5.0
>>(for a few reasons[5]), and this is too new for stock Mac OS X
>>(makeinfo 4.8).  However, it should be possible to make generated
>>*.info files part of the distribution archive and thereby reduce the
>>dependency load for people who _don't_ care about running "make doc"
>>(which demands an entire working TeX installation).
>>
>> Any guidance from readers, especially on issues 3-6, would be most
>> appreciated.
>>
>> Regards,
>> Branden
>>
>> [1]
>> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=2b3e0a672d426253025c32bff31fffe8439c47bc
>> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-September/090730.html
>> [3] For example:
>> afmtodit: both Delta and uni0394 map to *D at .../afmtodit line 6441.
>> afmtodit: both mu and uni03BC map to *m at .../afmtodit line 6441.
>> [4] pnmcrop: The image is entirely background; there is nothing to crop.
>> [5]
>> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=986d2a5b2d908c9d129f6d486e8839c2ec24f761
>>
>> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=d117bd8a2019ecc3ae8d41bf881b449d9e98b183
>>
>> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=63c7249ee502f69bed9da0b76a0e33c46a47332a
>>
>

Re: Portability to Mac OS X (was: Sed failure in contrib/sboxes on MacOS)

[John Gardner]

In lieu of escaped newlines and awkward sed(1) formatting, you can use the
following line to insert an empty line:

/^Before$/ { N; s/\n/&&/; }

Note that BSD sed(1) is picky about braces and semicolons.

 I have groff building successfully on Mac OS X now.
>

I recently upgraded to macOS 12.0.1 (Monterey), though I've not recompiled
Groff yet. Gonna do that now and report on any new issues.

However, it should be possible to make generated *.info files part of
> the distribution archive and thereby reduce the dependency load for
> people who _don't_ care about running "make doc" (which demands an
> entire working TeX installation).
>

Even better: a preprocessor to convert Texinfo markup to Roff source
(possibly targeting a macro package). I've said it before, and I'll said it
again: Groff needs TeX about as badly as it needs an Instagram page.

texi2roff(1) anyone? (I imagine it'd be fun to write in Perl…)

On Wed, 27 Oct 2021 at 16:10, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi, Andreas!
>
> At 2021-10-27T00:07:22+0200, Andreas Kusalananda Kähäri wrote:
> > Actually, that only makes it work with OpenBSD sed and GNU sed.  It
> > still fails with
> >
> >   sed: Unrecognized command: .lf 1 doc/webpage.ms
> >
> > when using Plan 9 sed.  Not tested with macOS.
> >
> > So it looks like the best bet is to insert a literal newline somehow,
> > after the \ like the Makefile *tries* to do.  How to do that properly
> > is unfortunately beyond me as I don't grock Make quoting rules very
> > well.
>
> It's a pretty rigid constraint problem.  The GNU Autoconf manual has a
> canned solution that I was able to adapt easily[1].
>
> I have groff building successfully on Mac OS X now.
>
> However, I see more work ahead of me.
>
> 1. There are 8 test failures.  These are probably portability failures
>in my scripts.
>
> 2. I want to check out a couple of compiler warnings.
>
> 3. The linker warnings I mentioned earlier on this list may be a
>long-standing LLVM issue with no resolution in sight.[2]  I don't
>intend to act on this unless someone with relevant expertise can
>advise me.  I hope the Homebrew folks know whether this is a real
>problem and if so, how to get around it.
>
> 4. afmtodit produces a lot more warnings on recent URW fonts than it
>does on my Debian buster system.[3]
>
> 5. pnmcrop is spewing warnings[4] and possibly we're getting blank
>images in pic.html and webpage.html as a result.  If a workaround
>cannot be found, I guess this means that yet another new Autoconf
>test that warns users of broken tooling is necessary.  :/
>
> 6. Some time ago I bumped our minimum required Texinfo version to 5.0
>(for a few reasons[5]), and this is too new for stock Mac OS X
>(makeinfo 4.8).  However, it should be possible to make generated
>*.info files part of the distribution archive and thereby reduce the
>dependency load for people who _don't_ care about running "make doc"
>(which demands an entire working TeX installation).
>
> Any guidance from readers, especially on issues 3-6, would be most
> appreciated.
>
> Regards,
> Branden
>
> [1]
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=2b3e0a672d426253025c32bff31fffe8439c47bc
> [2] https://lists.llvm.org/pipermail/llvm-dev/2015-September/090730.html
> [3] For example:
> afmtodit: both Delta and uni0394 map to *D at .../afmtodit line 6441.
> afmtodit: both mu and uni03BC map to *m at .../afmtodit line 6441.
> [4] pnmcrop: The image is entirely background; there is nothing to crop.
> [5]
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=986d2a5b2d908c9d129f6d486e8839c2ec24f761
>
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=d117bd8a2019ecc3ae8d41bf881b449d9e98b183
>
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=63c7249ee502f69bed9da0b76a0e33c46a47332a
>

Re: Sed failure in contrib/sboxes on MacOS

[John Gardner]

>
>  Yes.  Mac OS X, at least the version I have access to, uses Bash 3.2 as
> its script interpreter, and zsh 5.8 as its interactive shell.
>

It's more complicated than that. Apple have announced that the default
shell (Bash 3.2) will be removed in a future version of macOS, meaning `
/bin/sh` will point to zsh(1) instead of bash(1). There's already a
deprecation warning in-place warning users against relying on the existence
of /bin/bash or the assumption that /bin/sh == /bin/bash.

I recommend testing against both Bash 3.2 and Zsh. As for sed(1), this
might make cross-testing easier:

https://opensource.apple.com/source/text_cmds/text_cmds-106/sed/


> Perl's mostly from its much higher rate of development compared to the
> other two


You might be thinking of Python. Perl—more so than most programming
languages—takes backwards compatibility very seriously, as detailed in
perlpolicy(1) (see *"Backwards compatibility and deprecation"*). Scripts
can enable features for an explicit version of Perl via the `*use v5.N*`
pragma. That's also the reason `use strict` and `use warnings` aren't
enabled by default. 😉

Regards,
— John

On Wed, 27 Oct 2021 at 18:11, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi, James!
>
> I think the sed portability issues in the build are resolved for now,
> and pushed.
>
> At 2021-10-26T10:19:23-0400, James K. Lowden wrote:
> > I might have a useful platform to try. I am running autoconf 2.69 on a
> > NetBSD machine that I hardly ever change. Its sed and make are derived
> > from the same sources as the one you're using. I would be surprised if
> > the difference you're seeing is the product of shell quoting, since
> > the Mac uses bash.
>
> Yes.  Mac OS X, at least the version I have access to, uses Bash 3.2 as
> its script interpreter, and zsh 5.8 as its interactive shell.
>
> > BTW, is this episode yet another nail in the sed coffin? Is it another
> > reason not to rely on sed for whatever it is that it's doing?  I have
> > no dog in the fight, just asking.
>
> I don't think so.  My impression is that perhaps 90% or more of all sed
> usage is solely for its substitution operator, 1..n times.  But it's a
> Turing-complete language, so you can get up to all sorts of wonderful
> mischief in it.[1]
>
> The other languages one might turn to for reasonably sophisticated text
> processing tasks--AWK, Perl, and the Unix shell--all have their
> portability challenges as well (Perl's mostly from its much higher rate
> of development compared to the other two).  There are multiple competing
> implementations of all of these except Perl (which competes mostly with
> its own release history).
>
> I don't think there's a silver bullet.  We just have to try to write
> portably, and be prepared for bugs, unfortunate interactions between
> programs, and the inevitable impedance mismatches that arise from elbow
> room in standards documents, and strong personal feelings (about
> features, software licensing, or rival organizations) on the part of
> the humans behind the development process.
>
> Regards,
> Branden
>
> [1] http://sed.sourceforge.net/grabbag/scripts/dc.sed
>

Re: Two trivial questions

[John Gardner]

Initially, I pronounced it /ɡɹɔːf/
. Recently, I've
begun pronouncing it /ˈdʒiːɹɒf/
, though I sometimes
still mentally read it as the former.

IMHO, I think we should put our foot down and standardise Groff's
pronunciation in a man page somewhere. I'm willing to bet plenty of users
mispronounce "troff" as /tɹɒf/ 
(I used to be guilty of this myself).

 I'd further argue that the GNU roff project has indulged some puns that
> make the "jee-roff" pronunciation an unstable equilibrium that we might
> expect to fail.
>

The prefix these tools use isn't *"g-"*, but *"gro-"*; i.e., pronouncing
grops *"jee-rops"* only makes sense if there was a tool named "rops".

The surname "Groff", with which some unknown quantity of users will be
> familiar before they encounter our software, long predates computerized
> typesetting.
>

"Troff" is also a surname, albeit an uncommon one (see
https://unwsp.edu/bio/emma-troff/). Ergo, this argument doesn't have much
weight.


On Wed, 27 Oct 2021 at 17:04, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> [post-quotation word count: 565]
>
> At 2021-10-26T23:44:15-0400, Peter Schaffter wrote:
> > On Tue, Oct 26, 2021, Douglas McIlroy wrote:
> > > > Is there a correct pronunciation of groff?
> > >
> > > Groff's forebears were christened en-roff and tee-roff, so an
> > > old-timer from Bell Labs instinctively reads groff as a disyllable.
> > > Could groff's originator, James Clark, have read it otherwise?
> >
> > So is it worth giving the established pronunciation in the videos'
> > comments, or should language be left to do its thing and evolve?
>
> I'm still the new guy here in a lot of ways, and I've found my own usage
> shifting erratically between the two.  When I first showed up I mentally
> pronounced it "groff" (the monosyllable) just like the philistines with
> their YouTube channels, and I still do sometimes, but when speaking
> aloud to others about this thing that I work on, I sometimes find myself
> deferring to the "accepted" pronunciation.
>
> The surname "Groff", with which some unknown quantity of users will be
> familiar before they encounter our software, long predates computerized
> typesetting.  To the misfortune of our Web search efforts, it is borne
> by a couple of actors, at least one of whom is pretty famous, at least
> among some demographic groups (say, his own age or younger).
>
> I'd further argue that the GNU roff project has indulged some puns that
> make the "jee-roff" pronunciation an unstable equilibrium that we might
> expect to fail.  We have groff-related tools, grog and the output
> drivers, all of which[1] _seem_ to pull in the other direction.
>
> "Grotty" and "grog" are (at least) semi-standard English words, the
> latter a term for rotgut whiskey (or a ration of rum allocated to scurvy
> tars), and they thereby encourage a similar morphological approach to
> "groff".
>
> Do the old-timers instinctively pronounce grops(1) "jee-roe-pee-ess"?
>
> I pronounce the "gro-" prefix on all of our output drivers as "grow",
> and except for "grotty", spell out the remaining letters since they're
> all initialisms anyway.
>
> My guess is that the momentum will prove to be away from the disyllable.
> Our attempts to resist this will meet a further difficulty: our attempts
> at issuing corrections in writing meet with the misfortune that both of
> the two most common ways of doing so stumble over ambiguous readings in
> English, just as the interjection "Geez!" (or "Jeez!") does.[2]  When we
> say "gee-roff", does the first syllable more closely resemble "ghee"
> (that one might cook Indian food with) or the unit of acceleration
> experienced in aerobatic maneuvers?  When we say "jee-roff", we may
> think ourselves on firmer ground, but for every jeering, jersey-clad,
> jejune jellybean-jerker in the world, there's a person coming from a
> background in the French, German, or Spanish languages, familiar with
> English's aggressive adoption of loan words, who may be left wondering
> if we're suggesting "zhee-roff" or "yee-roff" instead.
>
> Consequently, for all of my inclinations as a prescriptivist, I find
> myself leaving my watermarked pad in its locked drawer in this case.
>
> Let the YouTubers mispronounce, if that is in fact what they're doing.
> I appreciate the publicity they're giving our little project, and if in
> so doing they encourage more people to read our documentation and gain a
> better command of the practical _usage_ of groff, I confess I'll be
> pleased.
>
> Regards,
> Branden
>
> [1] except for "gxditview", which doesn't encourage spoken pronunciation
> even slightly
> [2] I use the latter because it's a minced oath for "Jesus Christ": in
> popular (and characteristically hazy) notions of soteriology, even
> such mincing brings one nonzero ignominy in the 

Re: We have OSC 8 terminal hyperlink support now

[John Gardner]

I know it's probably a bit early for this discussion, but somebody on GitHub
raised a good question

:

Why x-man-page? dnf reports that yelp & khelpcenter provide man:// - but
> has no providers for x-man-page://
>

He was referring to an example I gave of a hyperlinked man page reference (
x-man-page://awk.1), which is supported on macOS (Terminal.app and iTerm2),
but not universally
.
Which invites the question—how are we going to hyperlink man page
references, specifically?

On Sat, 2 Oct 2021 at 14:02, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi all,
>
> I'm pleased to report that I've landed a new feature in groff Git HEAD.
>
> The grotty(1) output driver now recognizes a new "link" device control
> subcommand and uses it to synthesize ECMA-48 OSC 8 escape sequences to
> pass hyperlink information to the terminal device.  This means that, on
> terminal emulators that support OSC 8, groff documents can embed
> clickable hyperlinks.
>
> I tested this feature with gnome-terminal 3.30.2.  (My daily driver,
> xterm, doesn't support OSC 8 yet.)
>
> Here's how I've documented it in grotty(1).  It's linked with SGR
> support, another ECMA-48 feature.
>
> [...]
>By default, grotty emits SGR escape  sequences  (from  ISO  6429,
>popularly called “ANSI escapes”) to change text attributes (bold,
>italic,  underline, reverse-video, and colors).  Devices support‐
>ing the appropriate sequences can view roff documents using eight
>different background and foreground colors.  Following ISO  6429,
>the  following colors are defined in tty.tmac: black, white, red,
>green, blue, yellow, magenta, and cyan.  Unrecognized colors  are
>mapped  to  the default color, which is dependent on the settings
>of the terminal.  OSC 8 hyperlinks are  produced  for  these  de‐
>vices.
> [...]
>SGR and OSC support in pagers
>When paging grotty’s output with less(1), the latter program must
>be  instructed  to  pass SGR and OSC sequences through to the de‐
>vice; its -R option is one way to achieve this (less version  566
>or  later is required for OSC 8 support).  Consequently, programs
>like man(1) which page roff documents with less must call it with
>an appopriate option.
> [...]
>Device control commands
>grotty  understands  the  following device control functions pro‐
>duced using the roff \X escape sequence in a document.
>
>\X'tty: link [uri [key=value] ...]'
>   Embed a hyperlink using the  OSC  8  terminal  escape  se‐
>   quence.  Specifying uri starts hyperlinked text, and omit‐
>   ting  it  ends the hyperlink.  When uri is is present, any
>   number of additional key/value  pairs  can  be  specified;
>   their interpretation is the responsibility of the terminal
>   emulator.   Spaces or tabs cannot appear literally in uri,
>   key, or value; they must be represented  in  an  alternate
>   form.
> [...]
> Options
> [...]
>-c Use grotty’s legacy output format (see subsection  “Legacy
>   output  format”  above).   OSC 8 hyperlink terminal escape
>   sequences are not emitted.
> [...]
>
> Having already thus belabored the point, I trust the reader to infer
> that setting $GROFF_NO_SGR will also prevent the emission of OSC 8
> escape sequences.  (I say it here for the sake of future web searches.)
>
> People who maintain their own macro packages or eschew their use can put
> grotty(1)'s OSC 8 support to work immediately; it's a "git pull" away.
>
> To further demonstrate this feature, I have enhanced the groff man(7) UR
> and MT macro ("URL" and "mailto") implementations to use device control
> escape sequences to exercise it.  As planned and desired, this required
> to changes to any man page text; the hyperlinks simply appear.  When
> rendered, the link content will no longer be formatted as output (the
> hyperlinked _text_ of course, if any, will continue to be).
>
> The lack of universal support for OSC 8 and the absence of a means for
> the formatter to query terminal capabilities at runtime (a major
> architectural challenge given *roff design) however, means that I have
> disabled our man(7) implementation's use of the aforementioned device
> control by default for the time being, in the man.local file.
>
> Moreover, lack of terminal emulator support isn't even the biggest
> problem facing this feature; well-coded terminal emulators silently
> ignore OSC escape sequences they don't understand.  Unfortunately,
> another party often interposes itself in communications between
> grotty(1) and the terminal device--that

Re: We have OSC 8 terminal hyperlink support now

[John Gardner]

Hi Brandon,

That's one small step for a man... one giant leap for man(1)-kind. ;-)
Brilliant work!

I can't wait to update Mono.tmac  to
include it! Is there any reliable way for a macro-package to detect support
for this at runtime?

Also, I spotted a typo in the third sentence under the description of \X'tty:
link [uri [key=value] ...]'

When uri is *is* present,
>

s/(is )\K\1//;

— John

On Sat, 2 Oct 2021 at 14:02, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi all,
>
> I'm pleased to report that I've landed a new feature in groff Git HEAD.
>
> The grotty(1) output driver now recognizes a new "link" device control
> subcommand and uses it to synthesize ECMA-48 OSC 8 escape sequences to
> pass hyperlink information to the terminal device.  This means that, on
> terminal emulators that support OSC 8, groff documents can embed
> clickable hyperlinks.
>
> I tested this feature with gnome-terminal 3.30.2.  (My daily driver,
> xterm, doesn't support OSC 8 yet.)
>
> Here's how I've documented it in grotty(1).  It's linked with SGR
> support, another ECMA-48 feature.
>
> [...]
>By default, grotty emits SGR escape  sequences  (from  ISO  6429,
>popularly called “ANSI escapes”) to change text attributes (bold,
>italic,  underline, reverse-video, and colors).  Devices support‐
>ing the appropriate sequences can view roff documents using eight
>different background and foreground colors.  Following ISO  6429,
>the  following colors are defined in tty.tmac: black, white, red,
>green, blue, yellow, magenta, and cyan.  Unrecognized colors  are
>mapped  to  the default color, which is dependent on the settings
>of the terminal.  OSC 8 hyperlinks are  produced  for  these  de‐
>vices.
> [...]
>SGR and OSC support in pagers
>When paging grotty’s output with less(1), the latter program must
>be  instructed  to  pass SGR and OSC sequences through to the de‐
>vice; its -R option is one way to achieve this (less version  566
>or  later is required for OSC 8 support).  Consequently, programs
>like man(1) which page roff documents with less must call it with
>an appopriate option.
> [...]
>Device control commands
>grotty  understands  the  following device control functions pro‐
>duced using the roff \X escape sequence in a document.
>
>\X'tty: link [uri [key=value] ...]'
>   Embed a hyperlink using the  OSC  8  terminal  escape  se‐
>   quence.  Specifying uri starts hyperlinked text, and omit‐
>   ting  it  ends the hyperlink.  When uri is is present, any
>   number of additional key/value  pairs  can  be  specified;
>   their interpretation is the responsibility of the terminal
>   emulator.   Spaces or tabs cannot appear literally in uri,
>   key, or value; they must be represented  in  an  alternate
>   form.
> [...]
> Options
> [...]
>-c Use grotty’s legacy output format (see subsection  “Legacy
>   output  format”  above).   OSC 8 hyperlink terminal escape
>   sequences are not emitted.
> [...]
>
> Having already thus belabored the point, I trust the reader to infer
> that setting $GROFF_NO_SGR will also prevent the emission of OSC 8
> escape sequences.  (I say it here for the sake of future web searches.)
>
> People who maintain their own macro packages or eschew their use can put
> grotty(1)'s OSC 8 support to work immediately; it's a "git pull" away.
>
> To further demonstrate this feature, I have enhanced the groff man(7) UR
> and MT macro ("URL" and "mailto") implementations to use device control
> escape sequences to exercise it.  As planned and desired, this required
> to changes to any man page text; the hyperlinks simply appear.  When
> rendered, the link content will no longer be formatted as output (the
> hyperlinked _text_ of course, if any, will continue to be).
>
> The lack of universal support for OSC 8 and the absence of a means for
> the formatter to query terminal capabilities at runtime (a major
> architectural challenge given *roff design) however, means that I have
> disabled our man(7) implementation's use of the aforementioned device
> control by default for the time being, in the man.local file.
>
> Moreover, lack of terminal emulator support isn't even the biggest
> problem facing this feature; well-coded terminal emulators silently
> ignore OSC escape sequences they don't understand.  Unfortunately,
> another party often interposes itself in communications between
> grotty(1) and the terminal device--that would be the pager.  less(1)
> only developed OSC 8 support in version 566, released about one year
> ago.  Versions prior to that misinterpreted the OSC 8 escape sequence
> and would write parts of it to the terminal window, an unsightly mess
> that

Re: PROPOSED: semantics for an output line length of zero

[John Gardner]

> It seems that your input now works as you expected.  Is that correct?

Indeed. I'll let you know if I encounter any further errors.

Thanks for the speedy fix!

On Wed, 8 Sept 2021 at 01:15, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi John,
>
> At 2021-09-07T23:22:13+1000, John Gardner wrote:
> > I'm not sure I understand the issue here. For the purposes of
> > line-wrapping and word-breaking, `.ll 0` is essentially the same as
> > `.ll 1u`... isn't it?  Even in situations when a typesetter's quantum
> > of motion accommodates at least a single character, the output is
> > still the same; i.e.,
> >
> > I am \n[.l]u long.
> >
> > yields
> >
> > I
> > am
> > 1u
> > long.
> >
> > but also
> >
> > I
> > am
> > 0u
> > long.
> >
> > Am I missing something?
>
> Perhaps not, now that I've pushed a change to clamp the line length to
> the horizontal resolution of the output device[1].
>
> It seems that your input now works as you expected.  Is that correct?
> If so, I reckon we can close Savannah #61117.
>
> Regards,
> Branden
>
> [1] https://savannah.gnu.org/bugs/?61116
>
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=6e19da2ab0e360d5e48e5ef93ed32e6d703535a5
>

Re: PROPOSED: semantics for an output line length of zero

[John Gardner]

I'm not sure I understand the issue here. For the purposes of line-wrapping
and word-breaking, `.ll 0` is essentially the same as `.ll 1u`... isn't it?
Even in situations when a typesetter's quantum of motion accommodates at
least a single character, the output is still the same; i.e.,

I am \n[.l]u long.

yields

I
am
1u
long.

but also

I
am
0u
long.

Am I missing something?

On Sun, 5 Sept 2021 at 03:36, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> I'm proposing this on behalf on John Gardner, who raised it in a
> Savannah ticket[1].
>
> I asked him:
>
> >> What do you expect the semantics of an output line length of zero to
> >> be?
>
> He said:
>
> > Like this:
> >
> > This is your line-length
> >
> > This
> > is
> > your
> > line-
> > length
> > on
> > drugs
> >
> > Basically, print as many characters as you can fit up until the next
> > break opportunity (which could be whitespace or a hyphenation
> > opportunity, depending on hyphenation settings).
>
> This would be an extension to the semantics of the output line length;
> Heirloom Doctools troff (at least) instead clamps the output line length
> to the horizontal resolution.
>
> Does anyone have any thoughts on or objections to this?
>
> Regards,
> Branden
>
> [1] https://savannah.gnu.org/bugs/?61089
>

Re: Groff examples repository

[John Gardner]

>
> Since John Gardner will (rightly) insist that examples of mdoc(7) code are
> nothing more than mere examples of roff(7) code


To quote Heisenberg: *"You're goddamn right."* ;-)

The Groff examples repository is now available on the web at
> https://froude.eu/groff
>

Feel free to plunder my stupid macro package for anything you consider
worth sharing:

https://github.com/Alhadis/Mono

When copy+pasting from the macro package, be aware that many internal
registers and strings use names containing ASCII control characters, which
mightn't be visible in your browser/editor. Specifically, ^B, ^C, ^E, ^F, ^G,
^?.

On Mon, 30 Aug 2021 at 03:36, Ingo Schwarze  wrote:

> Hi Thomas,
>
> On 8/25/21, Thomas Dupond  wrote:
>
> > The Groff examples repository is now available on the web at
> > https://froude.eu/groff and on geminispace at gemini://froude.eu/groff
>
> Nice.
>
> I added a link to it to
>
>   https://mandoc.bsd.lv/links.html
>
> I think on your start page, you ought to add a link to
>
>   https://www.gnu.org/software/groff/ .
>
> Since John Gardner will (rightly) insist that examples of mdoc(7)
> code are nothing more than mere examples of roff(7) code, i would
> consider a link to
>
>   https://mandoc.bsd.lv/mdoc/
>
> useful as well; your call.
>
> If you want to add a full-blown example of how to use groff to
> set up a complete conference presentation, feel free to link to
>
>   https://www.openbsd.org/papers/eurobsdcon2018-mandoc.roff
>   https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf
>
> Parts of the contents of that presentation are also loosely related
> to roff(7), but that is incidental.  The point why it might matter
> here really is the full-blown example of setting up complete slides
> for a conference presentation.
>
> Yours,
>   Ingo
>
>

Re: Use various macro packages in the same page (was: Re: Plan 9 man added a new macro for man page references)

[John Gardner]

>
> But the mdoc(7) and man(7) languages can also be regarded as languages
> with a grammar


I wish people would stop referring to these as "languages". They're macro
packages, plain and simple: their "syntax" is that of the language they're
written in, Roff. How mandoc(1) implements and parses them is immaterial,
especially since mandoc's job isn't to be an implementation of Troff, but
to be a formatter for these two very specialised macro sets, using a
cherry-picked subset of language features.

It's difficult to get newcomers interested in Troff when they're frequently
being told that the program's input language isn't one, but several... only
to find out much later on how they really work, and that the system is less
complex than they initially believed.

On Wed, 4 Aug 2021 at 20:49, Ingo Schwarze  wrote:

> Hi Alejandro,
>
> Alejandro Colomar (man-pages) wrote on Wed, Aug 04, 2021 at 08:59:21AM
> +0200:
>
> > Is it possible to use more than one macro package at the same time?
>
> Branden already explained well how it is possible to use multiple
> auxiliary macro packages in addition to one full-service package,
> in general - except that doing so is undesirable in manual pages.
> He also explained how mdoc(7) and man(7) will get into a fight about
> the big picture, like page layout and the like.
>
> Another area of conflict is macro scoping, i.e. where (1) the
> syntactic scope of each macro and (2) its formatting effect
> begins and ends, and related nesting.  On the roff side, this whole
> topic is somewhat non-obvious because groff_mdoc(7) and groff_man(7)
> are implemented as macro packages, so on first sight, all that
> happens there is text replacements.
>
> But the mdoc(7) and man(7) languages can also be regarded as languages
> with a grammar and semantic significance attached to the grammatical
> elements, even though groff doesn't implement them that way.  Both
> languages can be compiled into an abstract syntax tree (AST), and that's
> what mandoc(1) does - and then the mandoc(1) formatters start their
> work from that AST.
>
> For both languages, that AST has a block structure, but the rules
> where blocks start and end, and whether and how they can nest, are
> vastly different.  In a nutshell, man(7) blocks mostly do not nest,
> whereas mdoc(7) blocks can not only nest to a depth of multiple
> level, but support - in contrast to languages like XML/HTML - what
> mandoc calls "bad nesting":
>
>   .Bf -emphasis
>   This is a block of italic text
>   .Po
>   with a parenthetic remark that starts italic
>   .Ef  \" end the scope of .Bf
>   and ends roman.
>   .Pc  \" end the scope of .Po
>
> I'm not saying relying on such features is good style in a manual page,
> only that scoping rules (which authors rarely need to worry about)
> are non-trivial under the hood and completely different in both
> languages.  While man(7) is simpler than mdoc(7) in this area, it does
> have one feature that mdoc(7) does not: next-line scoping:
>
>   .SH
>   Synopsis
>
> is equivalent to
>
>   .SH Synopsis
>
> in man(7), but not in mdoc(7).
>
> Then, while both languages have some macros that explicitly close
> blocks (.RE, .EE, .Ed, .El, .Oc, ...), both also have blocks that
> end implicitely - sometimes at the end of the input line (or the next
> input line for man(7)), sometimes at the beginning of certain other
> blocks.  These closing-out rules are again vastly different in both
> languages, even though authors usually don't need to be aware of
> them.
>
> However, if you start mixing both languages, scoping, nesting, and
> closing rules are all going to conflict.
>
> I`m not saying that cannot be solved.  The obvious, trivial solution -
> "mdoc blocks cant nest into man blocks and vice versa" - is not
> sufficent because you clearly want to permit mdoc content inside .SH
> and man content inside .Sh, and maybe even mdoc content inside .RS
> and man content inside .Bd.  So non-trivial new scoping, nesting,
> and closing rules would have to be developed.
>
> Regarding the social aspects, i agree with Alejandro's goal of
> helping transitions, but i also agree with Branden's doubts which
> kind of an impression mixed-language pages would make on package
> owners having to maintain them.  We just talked about the benefits
> of good code as a model for novice authors to look up to, and i
> wouldn't relish the idea of people starting to imitage mixed-language
> pages.
>
> When processing 2400 pages, the work clearly needs to be split into
> manageable chunks.  I think processing one group of pages, then the
> next one, and so on, using a translation tool and manual postprocessing,
> seems preferable to first changing one macro across all pages, then
> the next macro, and so on.
>
> Yours,
>   Ingo
>
>

Re: Question about ?roff on Reddit

[John Gardner]

>
> John's a sneaky devil.  I've never seen the .cw request used in anger
> before


I'm sorry, I meant to write `.cs`, which was superfluous anyway (since I
already set line-length to 1n, which forced lines to be wrapped). I was in
a rush and hastily repurposing code from an earlier snippet
,
one that counted the number of characters in a string in a fully portable
fashion. In hindsight, I should've disabled hyphenation as well… apologies
for that.

As for the thread, I don't feel qualified enough about TeX to offer an
insightful opinion, as my experience with TeX is limited to one or two
documents—neither of which were fun to produce.

On Fri, 16 Jul 2021 at 23:36, Oliver Corff  wrote:

> When I followed the first reddit link a few days ago for the first time,
> I read a few contributions and thought that it could be a challenge to
> reconcile the discrepancy between the internalized knowledge about
> things related to the "black art" (typesetting, that is) generally
> prevalent in this community here, not to speak of all the *roff details,
> on one hand, and the knowledge level present among the reddit readers on
> the other hand, as it came to my mind that any posting intended to be
> enlightening might unnecessarily appear highbrow and scare away
> potential readers who otherwise could develop an interest in things *roff.
>
> One question was similar to: "Are there any documents typeset in *roff
> which I can find in the net?", while a different posting already
> mentioned all the books typeset in *roff. But perhaps even Kernighan &
> Ritchie's "Programming in C" seems to be a thing of the remote past
> (given that it was published in 1988). I utterly fail to relate to that
> feeling, but is it really possible that one considers a book written
> before one was presumably born as outdated per se? (I assume the age
> median in the reddit group to be lower than here, but I may be wrong.)
>
> Yet, something like a gentle introduction about the fundamental
> differences, strengths and weaknesses of markup vs. typesetting vs. text
> processing would be a good idea. But, so many of these gentle
> introductions have already been written, and with so many platforms
> emerging (I assume the intersection set between gnu mailing list users,
> usenet group readers and reddit visitors is small, but was recently
> successfully demonstrated to be non-empty) it is pretty probable that
> every new "generic" and "gentle introduction" will miss its target
> audience if it is not published where its readers spend their time.
>
> On the other hand, the second, recent reddit link posted here
> demonstrates quite a level of insight among the contributors, compared
> to the other one.
>
> The only thing that can be done is to post a list of pointers to the
> groff site, to this mailing list (after all, it can be browsed in its
> entirety without registering anywhere --- also soon becoming a thing of
> the past, I am afraid), and perhaps to introductory articles in Wikipedia.
>
> The youtube postings were mentioned, too; that seems to be yet another
> clientele. Be it so --- good to have!
>
> Best regards,
>
> Oliver.
>
>
> On 16/07/2021 14:36, John Ankarström wrote:
> > Den 2021-07-16 kl. 03:50 skrev Nate Bargmann:
> >> I learned there is a Groff Reddit as well:
> >>
> >> https://www.reddit.com/r/groff/
> >>
> >> It seems to have quite a bit of activity which is fantastic.
> > I was just about to write this. I am relatively active on /r/groff (as
> > user quote-only-eee) and it would be great to see some more activity on
> > it, if there are other people here who have Reddit accounts. It is an
> > obvious place for beginners to ask questions.
> >
> > Perhaps I should contact moderator HexDSL about putting up information
> > about the groff mailing list on the subreddit, as many people who post
> > there presumably don't know about it.
> >
> >
>
>

Re: Modernising UNIX manpages.

[John Gardner]

>
> I would like to investigate the possibility of using Markdown as an
> alternate format for UNIX man-pages.


You picked the worst possible markup imaginable. Not just for man pages,
but for any technical documentation, *period*. If you're interested in
"modernising", I suggest rewriting man pages to use mdoc(7).

Markdown has one feature: readability. That's literally it.

On Thu, 22 Apr 2021 at 02:57, Eric S. Raymond  wrote:

> JM Marcastel :
> > Dear all,
> >
> > I would like to investigate the possibility of using Markdown as an
> alternate format for UNIX man-pages.
> > (Cf. https://github.com/marcastel/marcastel/discussions/7)
> >
> > Rather than re-inventing the wheel I would ideally like this to become
> part of an existing tool (mandoc, groff, …).
> >
> > I would like to devote time to this in the second semester of 2021 and
> would appreciate sharing this.
> >
> > I believe the first step is to provide a proof of concept what
> demonstrates the expected outcome and that desired command line interface.
> >
> > I have a clear idea on how to build that POC once the requirements have
> been set.
> >
> > Has this already been studied? Would this be an initiative you would
> support?
> >
> > Best regards,
> > JM Marcastel
>
> I've studied the problem of moving man pages to a less Paleolithic format
> very closely.  I've even
> written a program that automates the process pretty effectively -
> doclifter.
>
> Here's what I know.
>
> 1. Sorry, Markdown is a *terrible* choice.  Which dialect? It's simply not
> standardized enough.
> It's also semantically rather weak, especially near tables.
>
> 2. DocBook-XML is excellent at capturing the kinds of semantics you
> wamt for very sophisticated querying.  It also renders to very good HTML,
> better
> that you can make from a weaker markup. But it has one serious flaw - it's
> sufficiently
> heavyweight to be unpleasant for human editors.
>
> 3. Presently I master my manual pages in asciidoc.  It can be rendered to
> XML-DocBook,
> is much easier to write, and is enough stronger and more standardized than
> Markdown
> to be a clearly better choice. Its only serious drawback reklative to
> XML-DocBbook
> is that you lose the ability to do structured markuo of command synopses.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
>
>
>

Re: Interesting articles

[John Gardner]

Of course, *both* solutions are inadequate when you consider languages
other than English  (especially
agglutinative languages like Hungarian and Turkish). For example, how many
"words" are in "
*muvaffakiyetsizleştiriciveremeyebileceklerimizdenmişsinizcesine"…?*

Pedantry aside, good find! Next time I'm asked how Troff differs
philosophically from TeX, I'll cite this article as a condensed example.


On Fri, 26 Mar 2021 at 13:31, Larry Kollar  wrote:

> Sometimes, my Twitter feed coughs up some cool articles, like
> this one: "Performance comparison: counting words in Python,
> Go, C++, C, AWK, Forth, and Rust”
>
> https://benhoyt.com/writings/count-words/
>
> The Awk solution was by far the shortest by line count. Since
> the runtime for all the different solutions was a few seconds or
> less, Awk was probably the fastest because it took the least time
> to code. :D
>
> But there was a passage that made me laugh out loud:
>
> > Incidentally, this problem set the scene for a wizard duel
> > between two computer scientists several decades ago. In
> > 1986, Jon Bentley asked Donald Knuth to show off “literate
> > programming” with a solution to this problem, and he
> > came up with an exquisite, ten-page Knuthian masterpiece.
> > Then Doug McIlroy (the inventor of Unix pipelines) replied
> > with a one-liner Unix shell version using tr, sort, and uniq.
>
> I can imagine the shell pipeline also look less time to type in and
> run than it did to code the literate programming solution. For
> one-off things like this, less code is better.
>
> Then there was the article “Taco Bell Programming”
>
> http://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html
>
> There were several good takeaways in this one, but my favorite
> line was “functionality is an asset, but code is a liability.” Not to
> mention the casual comment that xargs supports parallel processing
> (something I was totally unaware of!).
>
> — Larry
>

Re: Mangled pdf in Chrome browser?

[John Gardner]

Also perfect on macOS.
Big Sur 11.2.1, Chrome 88.0.4324.182 (Official Build) (x86_64)


On Sun, 21 Feb 2021 at 05:35, Heinz-Jürgen Oertel 
wrote:

> Am Samstag, 20. Februar 2021, 17:42:09 CET schrieb Peter Schaffter:
> > A user contacted me off list saying that the example pdf file at
> >
> >   https://www.schaffter.ca/mom/pdf/sample-formatted-article.pdf
> >
> > is rendering as garbage in the Chrome browser.  I don't use Chrome.
> > Can someone check if this is true?
> >
> >
> perfect on
> Linux Chrome Version 88.0.4324.182 (Offizieller Build) (64-Bit)
>
> Heinz
>
>
>
>
>

Re: ^G

[John Gardner]

Hi Branden,

> As I understand it, there is a tradition in GNU Emacs
> of using ^L as a page break character, and it is
> therefore an expectable character in an otherwise
> "plain text" stream.  If Version 7 Unix troff didn't
> support ^L in identifiers, it might have been injected
> into groff's set to placate the Emacs community.

That no doubt stems from the historical use of form feed (^L) characters to
indicate a literal page-break to an actual printing device. I've seen form
feeds used to demarcate sections within a file in the original Osannah
Troff's source code; even vi(1) considers form feeds to be section markers
(for the purposes of its { and } commands).

Most printers today still recognise form feeds as page-breaks when printing
plain-text output.

Cheers,
— John

On Mon, 15 Feb 2021, 4:30 pm G. Branden Robinson, <
g.branden.robin...@gmail.com> wrote:

> Hi Wim and John,
>
> At 2021-02-02T23:11:39+1100, John Gardner wrote:
> > Hi Wim,
> >
> > Roff syntax permits certain ASCII control characters in identifiers.
> > They're typically used by older macro-packages to avoid naming
> > conflicts, or in contexts when an arbitrary delimiter may appear in
> > legitimate texts (such as the .tl request).
>
> Since GNU troff's parser has a concept of "input level"--which is
> mentioned but unfortunately not actually defined in our Texinfo
> manual--.tl requests, among other things, are robust to this sort of
> confusability.
>
> Try the following with, say, "nroff":
>
> .pl 2v
> .de TL
> .  tl 'left'\\*T'right'
> ..
> .ds T You won't get it up the steps.\"
> .TL
> .cp 1
> .TL
>
> > Acceptable control characters are:
> >
> >- ^B STX (Start of text)
> >- ^C ETX (End of text)
> >- ^E ENQ (Enquiry)
> >- ^F ACK (Acknowledge)
> >- ^G BEL (Alarm / bell)
> >- ^? DEL (Delete)
> >
> > Groff also accepts ^D (End of transmission) and form feeds, although
> > the latter might be unintentional.
>
> As I understand it, there is a tradition in GNU Emacs of using ^L as a
> page break character, and it is therefore an expectable character in an
> otherwise "plain text" stream.  If Version 7 Unix troff didn't support
> ^L in identifiers, it might have been injected into groff's set to
> placate the Emacs community.
>
> Or one GNU Emacs user in particular...
>
> > On Tue, 2 Feb 2021 at 20:23, Wim Stockman 
> wrote:
> >
> > > What is the purpose of this? ^G , control character.
> > > I see it a lot used in the hdtbl macro set.
>
> I'm not sure hdtbl's uses are necessary.  I see only a few usage
> patterns.  It's a point worth researching.  My _expectation_ is that
> arguments to the \A and \B escapes change the input level, and both of
> these are groff extensions anyway, so won't work in compatibility mode.
> If I'm right, then these uses of ^G can be replaced with ' or almost
> anything else.
>
> In hdmisc.tmac-u, an .index (like index(3)) string operator is defined.
> I haven't looked closely, but I think the algorithm uses the ^G as a
> marker that is not expected to occur in the string being searched.  But
> if it does, it won't work...
>
> In common.roff there is a third case, using \w, a portable escape.  It's
> like the \A and \B case except the context should be checked to see if
> it's possible that we're in compatibility mode.
>
> This is a superficial investigation as I'm pressed for time right this
> second.
>
> My preference would be to get rid of these control characters in our
> sources if possible.
>
> $ grep -r '^G' contrib/hdtbl | cat -v
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[cols]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[cpd]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[csp]^G \
> contrib/hdtbl/hdtbl.tmac-u:.  ie \B^G\\*[border]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[height]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[height]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[rowspan]^G \{\
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[colspan]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\*[**]^G \
> contrib/hdtbl/hdtbl.tmac-u:.ie \B^G\\$[\\n[*]]^G \
> contrib/hdtbl/hdmisc.tmac-u:.  length ** \\$1^G
> contrib/hdtbl/hdmisc.tmac-u:.ds * \\$1^G\"
> contrib/hdtbl/examples/common.roff:.  nr *w* (17 * \w^G\\$*^G / 10 + 4n)
> contrib/hdtbl/examples/common.roff:.  if !\B^G\\$1^G \{\
> contrib/hdtbl/examples/common.roff:.ie !\B^G\\$2^G \
> contrib/hdtbl/examples/common.roff:.ie !\A^G\\$3^G \
>
> Regards,
> Branden
>

Re: ^G

[John Gardner]

Hi Wim,

Roff syntax permits certain ASCII control characters in identifiers.
They're typically used by older macro-packages to avoid naming conflicts,
or in contexts when an arbitrary delimiter may appear in legitimate texts
(such as the .tl request).

Acceptable control characters are:

   - ^B STX (Start of text)
   - ^C ETX (End of text)
   - ^E ENQ (Enquiry)
   - ^F ACK (Acknowledge)
   - ^G BEL (Alarm / bell)
   - ^? DEL (Delete)

Groff also accepts ^D (End of transmission) and form feeds, although the
latter might be unintentional. For full details on compatibility, see

https://gist.github.com/Alhadis/b3931ccde8390de8c685bcc582a7060d#file-readme-md


(This page excludes details for mandoc(1), as its syntax deviates from
traditional Troff implementations w.r.t. valid identifier characters. I
told Ingo about the discrepancy, but he seems reluctant to fix it).

Cheers,
— John

On Tue, 2 Feb 2021 at 20:23, Wim Stockman  wrote:

> What is the purpose of this? ^G , control character.
> I see it a lot used in the hdtbl macro set.
>
> Kind regards
> Wim Stockman
>

Re: Huge Filesize of PS file 12M

[John Gardner]

>
> Because I still see a lot of this [in the Postscript file]. Can I somehow
> remove them. I don't need all those special characters.


In PostScript, you can "initialise" an array with a value with

/Encoding [
255 {/.notdef} repeat
] def

% Set array entries individually
Encoding 0  /asciicircum put
Encoding 34 /quotedblput

% Print contents of array to stdout for inspection
Encoding ==


Compressed, that becomes:

/E[255{/.notdef}repeat]def E 0/asciicircum put E 34/quotedbl put


I use an enhanced alternative

to PostScript's built-in `==` operator, which is imported with:

%!PS
(/path/to/inspect.ps) run

% Usage:

<< /foo (Bar) /baz (Qux) >> ===

(Check gs(1) for details on the library search-path and invocation syntax).

Cheers,
— John (@Alhadis )



On Sat, 23 Jan 2021 at 10:08, Wim Stockman  wrote:

> Hi, Thank you Werner for your great input.
> So I'll leave the embedded fonts out and take it a step further.
> I'm thinking of going old school. I generate once a nice stationary
> letterhead with groff.
> and for the letters themselves I start them at the right vertical
> position..
> I looked it up with the \n[ln] register. So I know where to start. And if
> they need printing or mailing.
> I create a small script two stamp the letter on to the stationary.
> I tried this out and worked like a charm.
>
> I even added gzip to reduce the postscript files which slashed the file
> size even more by 50%
> So now I have a one time stationary letter file of 88KB which contains two
> company logos. and an average letter that is around 10KB
> When I gzip them I have the header of 40KB and the average letter is less
> than 3KB.
> This is quite a victory coming from 12MB a file.
> Thank you ,
> Kind regards
> Wim Stockman
>
> Op do 21 jan. 2021 om 11:12 schreef Werner LEMBERG :
>
> >
> > > So thank you for the tip. I disabled the fonts in the /devps/download
> > file
> > > and it went from 12MB to 92K so that is already a big step forward.
> > > Is there a better way to disable the embedding of fonts ?
> >
> > Not that I'm aware of.
> >
> > > Because I still see a lot of this :
> > > "
> > > grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72
> > > def/PL 841.89 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron
> > > /Zcaron/scaron/zcaron/Ydieresis/trademark/quotesingle/Euro/.notdef
> > >
> /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
> > >
> /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
> > >
> /.notdef/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent
> > > /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen
> > > "
> > > in the Postscript file.  Can I somehow remove them. I don't need all
> > > those special characters.
> >
> > No, you can't.  Those arrays are encoding vectors necessary to access
> > those fonts in general, regardless whether they are embedded or not.
> >
> > As I told you in the previous e-mail: You need to postprocess groff's
> > PS output to get something smaller since font subsetting is not
> > implemented.
> >
> >
> > Werner
> >
>

Re: Groff algorithm

[John Gardner]

Both syntax highlighting and elegant algorithm specifications would make
great preprocessors. ;-) I find the latter works best when used tastefully
(and never, *ever* in a manual page).

It'd be trivial to write an Awk script for replacing basic-looking
keywords, substituting them with proper placement and formatting controls:

.begin algorithm
IsMultipleOf (input, value)

assert value is Integer

assert value is >= 0

value := 10

result := undefined

unless input % value

return true

else

return false

.end


This might expand to pic(1) instructions, eqn(1), or a list of steps for
human consumption like this one .
I vaguely recall somebody wrote a preprocessor to format *BNF grammars into
a pic(1) drawing that looked extremely spiffy. Sadly, I never saved the
link…




On Wed, 13 Jan 2021 at 07:23, M Douglas McIlroy <
m.douglas.mcil...@dartmouth.edu> wrote:

> > I wonder how I can format a nice algorithm in the usual sense in groff.
> > I want to write pseudocode...\
>
> It all depends on what you mean by "nice". If it's just a properly indented
> listing, most of the standard macro packages have adequate support.
> For example, in the -ms package (man 7 groff_ms) bracket the code with
> .DS and .DE and use .ta to set tabs. However,. groff will not serve as a
> pretty-printer and decide how code should be indented.
>
> It's customary also to use a constant-width font for programs: .ft CW. But
> you
> may not want to do so for pseudocode.
>
> If you want syntax highlighting, e.g. bold keywords of (heaven forfend)
> syntax
> colorization. it will be painful, but straightforward: use \f and \m
> escapes to
> change font and color.
>
> Doug
>

Re: [HELP] [bug #55475] Segmentation fault in libgroff:relocatep

[John Gardner]

>
> In fact, we could really use ongoing assistance from someone with a
> Windows environment to test builds on.


These VirtualBox images might help to bridge a few gaps…

   - https://archive.org/details/ie6.xp.virtualbox
   - https://archive.org/details/ie8.xp.virtualbox
   - https://archive.org/details/ie8.win7.virtualbox
   - https://archive.org/details/ie9.win7.virtualbox
   - https://archive.org/details/ie10.win7.virtualbox
   - https://archive.org/details/ie11.win7.virtualbox
   - https://archive.org/details/ie11.win81.virtualbox
   - https://archive.org/details/msedge.win10.virtualbox

These contain 90-day trial versions of Windows, formerly provided by
Microsoft for web developers testing their sites against legacy versions of
Internet Explorer. After a while, Microsoft stopped bothering to host older
VMs altogether:

   - https://github.com/xdissent/ievms/issues/341
   - https://gist.github.com/zmwangx/e728c56f428bc703c6f6

I uploaded a copy of each VM I was fortunate enough to find a mirror for. I
did this out of historical curiosity (and also to spite anybody at
Microsoft hoping to whitewash memories of IE6 from the world, heh). FWIW, I
cross-checked the SHA256 sums of a few images with those I happened to have
backed up to a portable hard-drive. That's more of an anecdote than a
statement about file integrity, though.

*@Branden*: I recommend mounting these images in VirtualBox without network
access or write access to shared folders. Download installer files ahead of
time and expose it as a read-only shared directory. If MinGW doesn't work, GOW
should work . I'm sure you can work out
the rest. ;-)

Once the 90-day trial period expires, you'll be limited to time-locked
Windows sessions (unless you reinstall the VM from scratch; note that
rolling back to a VM snapshot doesn't always fool Windows).








On Wed, 6 Jan 2021 at 16:17, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> [redirecting from bug-groff@]
>
> I deeply hate hacking on C when I have no reproducible test case I can
> use and no access to a system that exercises the code paths I'm
> troubleshooting.  But this bug has been sitting for a long time and it
> seems no one wants to touch it.
>
> Details below.
>
> `make distcheck` passed for each of these commits on my Debian-based
> x86-64 system but that doesn't tell us much since the problem only ever
> manifested on other configurations.
>
> I could use confirmation of two things:
>
> (1) What happens when Guix reverts the workaround patch discussed in
> , letting this
> code get exercised.  I predict an assertion failure.  If I'm right,
> then the bug has been RCAed and we can decide how to make
> relocatep() cope with the issue.
>
> (2) Whether these changes break things for Windows users.
>
> In fact, we could really use ongoing assistance from someone with a
> Windows environment to test builds on.
>
> Regards,
> Branden
>
> At 2021-01-05T23:59:10-0500, G. Branden Robinson wrote:
> > Update of bug #55475 (project groff):
> >
> >   Status:   Confirmed => Need Info
>
> >  Assigned to:None => gbranden
>
> >
> > ___
> >
> > Follow-up Comment #5:
> >
> > Well, no one has stepped up to this, and I can't reproduce it, but I also
> > can't stand the thought of groff 1.23.0 going out with this bug, so with
> > considerable discomfort I took a stab at it.
> >
> > I've pushed the following 3 commits to try and get at the issue.  A tar
> > archive of the tree can be obtained from:
> >
> >
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=2fabd352f4ccdb382acffb7705a129977a2768d3
> >
> > Or I can easily prepare a distribution archive from any of these three
> points
> > if that would help.
> >
> > I need someone's help to confirm whether the issue has been resolved, or
> to
> > observe the assertion failure!
> >
> >
> > commit 2fabd352f4ccdb382acffb7705a129977a2768d3 (HEAD -> master,
> > origin/master, origin/HEAD)
> > Author: G. Branden Robinson 
> > Date:   Wed Jan 6 15:48:39 2021 +1100
> >
> > src/libs/libgroff/relocate.cpp: Shift #ifdef.
> >
> > * src/libs/libgroff/relocate.cpp (set_current_prefix) [!_WIN32]: Move
> >   logic attempting to set `curr_prefix` by calling searchpathext()
> from
> >   here...
> >   [WIN32]: ...to here.  The PATHEXT environment variable has
> semantics
> >   only under Windows, not POSIX systems, so the placement of this
> code
> >   seemed erroneous.
> >
> > commit c2f0e424e4a2bdcd287c8be9957daf93a581673a
> > Author: G. Branden Robinson 
> > Date:   Wed Jan 6 15:43:57 2021 +1100
> >
> > src/libs/libgroff/relocate.cpp: Fix memory leak.
> >
> > * src/libs/libgroff/relocate.cpp (set_current_prefix) [_WIN32]:
> Allocate
> >   memory from heap for `curr_prefix` only on Windows; on othe

mdoc: `.Os` macro should stop validating versions

[John Gardner]

As of this writing, the latest releases of Darwin are 20.2.0 (stable) and
20.3.0 (beta), respectively corresponding to macOS 11.1 and macOS 11.2
beta. However, the `doc-operating-system-*` strings defined in
tmac/mdoc/doc-common-u only count up to 19.2.0.

Obviously, keeping this list up-to-date is an exercise in futility, as
actively-maintained platforms wheel out new releases all the time. I don't
know how important these string definitions are for backwards
compatibility, but .Os should at least accept an unrecognised version
number without complaint.

mandoc(1) already trusts the *version* parameter of the .Os macro, even if
it's from an ostensibly non-existent version. Groff should do the same;
even for historic platforms, validating version strings is outside the
scope of a macro package's responsibilities.

Re: End-of-sentence spacing

[John Gardner]

>
> It was neither the only, first, last, or most vituperous critique of Two
> Spaces: There has been a rising tide of condemnation of the practice in the
> media, as shown by Googling "two spaces after period".
>

I condemn two spaces, period.

Worst\. Indentation style\. Ever.

On Tue, 22 Dec 2020 at 09:45, Dave Kemper  wrote:

> On 12/20/20, Dorai Sitaram via  wrote:
> > It was neither the only, first, last, or most vituperous critique of Two
> > Spaces: There has been a rising tide of condemnation of the practice in
> the
> > media, as shown by Googling "two spaces after period".
>
> As a general rule, you can gauge how seriously to take someone's
> critique of any topic by calculating the ratio of the topic's relative
> importance in the world to the commenter's level of vituperousness.
> The more shrilly someone rails against something of such little
> consequence, the more safely you can ignore them. :-)
>
> You'll also observe that a lot of opinionated people fail to
> distinguish between input convention and typesetting (probably trained
> by Word that these aren't separate topics), or misrepresent the
> history of the practice (often with variations on the demonstrably
> false claim that wider sentence spacing originated with typewriters
> and/or monospace typefaces).
>
>

Re: groff: grops and grodvi crash on invalid input

[John Gardner]

>
> What do you think about a warning for drawing outside the page boundaries?


I can't see that benefiting anybody, quite frankly. Since all coordinates
are precomputed, users are unlikely to see such a message in practice.

Personally, I find Groff's postprocessors too chatty, and would really
appreciate having the ability to silence certain warnings. Perhaps
something like:

x warn -unknown-x-cmd +out-of-bounds


… which would enable your proposed warning addition, and disable this
sodding message I'm sick of seeing:

grotty::15: error: X command without 'tty:' tag ignored


(For reference, it's complaining about the \X'meta: …' directives I
embedded in a few macros)



On Mon, 23 Nov 2020 at 02:46, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> At 2020-11-23T00:10:15+1100, John Gardner wrote:
> > IMHO, it would be more intuitive to make this
> [a positioning command before the first 'p' command]
> > a no-op, rather than an error (a warning at *most*). Users may wish to
> > "prepostprocess" the formatted output to control page order, extract
> > or inject existing pages from an earlier formatting run (etc)… things
> > that elevate the risk of an errant motion command appearing before the
> > first p command.
>
> Fair point.  Yes.  I'd like to see a warning for it, but nothing more
> drastic.
>
> > Roff.js, being designed to accommodate a range of troff
> > implementations and perform unattended document formatting, is
> > deliberately tolerant of input it doesn't expect (to a fault: I
> > actually need to make it a little stricter with error reporting...
> > I'll get back to that in 2021 probably…)
>
> Everybody's liberal in what they accept until the QAnon trolls and other
> defectors from the social contract show up, then they remember that
> norms are there for a reason.  ;-)
>
> What do you think about a warning for drawing outside the page
> boundaries?  N.B. I don't know how to actually implement such a thing
> yet.
>
> Thanks for the feedback!
>
> Regards,
> Branden
>

Re: groff: grops and grodvi crash on invalid input

[John Gardner]

>
> He declared a groff-compatible ps device resolution of 72000 but didn't
> scale his arguments.


That's assuming he didn't patch devps/DESC locally with an arbitrary `
sizescale` or `unitwidth` parameter (which may have been an attempt to make
coordinates easier to visualise). But your point still stands.


That's documented in groff_out(5) as against the rules.


IMHO, it would be more intuitive to make this a no-op, rather than an error
(a warning at *most*). Users may wish to "prepostprocess" the formatted
output to control page order, extract or inject existing pages from an
earlier formatting run (etc)… things that elevate the risk of an errant
motion command appearing before the first p command.

Roff.js, being designed to accommodate a range of troff implementations and
perform unattended document formatting, is deliberately tolerant of input
it doesn't expect (to a fault: I actually need to make it a little stricter
with error reporting... I'll get back to that in 2021 probably…)


Now this part is really weird.  I don't know where those came from.


Probably Gmail. Google probably converts the line-endings of *.txt
attachments to make life less shit for Windows users, since less
tech-literate people won't understand why Notepad.exe is displaying
everything on "one huge line".

Re: groff: grops and grodvi crash on invalid input

[John Gardner]

>
> In the meantime, John Gardner, who's written his own "ditroff"
> interpreter in JavaScript, might be able to offer some useful insights
> on the well-formedness of your sample documents.


Sorry, I completely missed this.

The samples look fine. Try converting their line-endings from CRLF to LF
and see if that fixes it.

On Wed, 18 Nov 2020 at 20:15, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:

> Hi Brian,
>
> Following up on an almost 14 year old bug report...
>
> I can't reproduce these SEGVs with groff git HEAD.  I would have thought
> they're the same bug since the groff output drivers outsource all of
> their parsing to the driver library, src/libs/libdriver/input.cpp.
>
> However, there's some suggestive evidence that's not the case.
>
> I cannot reproduce the grops SEGV with groff 1.22.4 from Debian.
>
> I _can_ reproduce the grodvi SEGV with groff 1.22.4, but neither SEGV
> happens with groff git HEAD.  The only change to the source code that
> can conceivably explain that in the meantime is this:
>
> commit 5d0990500c2d16ed1025f1f0738cb419800652fe
> Author: G. Branden Robinson 
> Date:   Thu Jun 27 04:42:51 2019 +1000
>
> libdriver: Fix SEGV (Savannah #56555).
>
> Check result of set_char_and_width() for error condition before relying
> on it.
>
> ...but I'm not too sure.  groff 1.22.4 with grops might be working for
> me out of dumb luck.  But your commands _are_ trying to set glyphs,
> so...maybe.
>
> Incidentally the libdriver diagnostics are both too verbose and too
> vague.  You get doubled diags for failures parsing a 'c' construct but
> for most other "ditroff" commands, the most you will get is "missing
> argument" and a line number, which is especially dopey because the
> format is loose enough to allow multiple commands per line in many
> cases.
>
> I have a sketch for a fix for these problems.  It's ugly enough that I
> expect some pushback from the groff mailing list over its esthetics.  So
> let's get that out of the way--I'll CC them.
>
> In the meantime, John Gardner, who's written his own "ditroff"
> interpreter in JavaScript, might be able to offer some useful insights
> on the well-formedness of your sample documents.
>
> Regards,
> Branden
>

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

[John Gardner]

>
> A pity there’s no OpenType version.


Somebody already made one
, although the link
 they gave is dead. Fortunately, I saved it.

One of these days I'll do a high-quality, hand traced version that matches
the bitmap version when rendered at the original resolution. That's going
to involve a whole lot of squinting and polishing in Adobe Illustrator,
though. :-)

On Wed, 4 Nov 2020 at 16:31, Werner LEMBERG  wrote:

>
>  There's a Linux version too, if you're interested:
>  https://github.com/talamus/solarize-12x29-psf
> >>>
> >>> A pity there’s no OpenType version.
> >>
> >> Attached :-)
> >
> > Bitmap font embedded in a TTF?
>
> Yep.  This should be portable, contrary to the PSF version.  No idea
> whether a real outline version exists – if yes, it's probably not
> freely available.
>
>
> Werner
>


gallant12x22.ttf
Description: Binary data

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

[John Gardner]

>
> A different way to talk about it, maybe more clearly, would be to talk
> about a "literal mode", which would have two distinct effects:


That's already possible using the .tr and .eo requests. Best not to
duplicate existing functionality.

In man(7) - or more precisely, in man-ext - the .EX macro already does .do
> fam C .


Trouble is, many authors don't use .EX in practice. Instead, it's quite
common to see stuff like this:

.RS
.nf
\&*code*
\&*goes*
\&*here*
.fi
.RE


Stuff like this is what we should be fixing, IMHO.

On Tue, 3 Nov 2020 at 22:22, Ingo Schwarze  wrote:

> Hi John,
>
> this seems a bold, novel, and interesting idea to me.  I'm not yet
> completely sure whether it's viable, but it might be.  I'm not sure
> how difficult it would be to implement in groff.  In mandoc, it is
> certainly possible.
>
> The rest of this reply addresses a few details.
>
> Yours,
>   Ingo
>
>
> John Gardner wrote on Mon, Nov 02, 2020 at 11:24:49PM +1100:
>
> > I think it's time we took constant-width fonts seriously when
> > preparing output for the terminal. Here me out on this:
> >
> > You see, I've never, *ever* needed fancy typography when typesetting
> > code samples, which are invariably set in a fixed-pitch (monspace)
> > typeface.
>
> I agree.  That's often done, it's not always done, but would almost
> always be the right thing to do.
>
> > The use of a fixed-pitch font stipulates the author's expectation
> > that that verbatim input should *stay* verbatim.
>
> This may not be true in every conceivable typesetting situation.
> But in manual pages, i do agree that's a very reasonable assumption.
>
> Besides, even in the very unusual case of an author desiring
> curly quotes in a fixed-width font in a manual page, they can
> readily use \(oq...\(cq even when the rule you propose is in force.
>
> > On the other hand, nobody in their right mind would deliberately
> > write source-code in a proportional typeface, so we can trust the
> > use of Georgia or Helvetica to indicate body text - stuff
> > for reading and styling.
>
> There might be exceptions in some unusual typesetting situations
> (e.g. obfuscated code contests / ASCII art and the like), but in
> manual pages, again, i think this is a completely reasonable
> assumption.
>
> Besides, even in the very unusual case of an author desiring
> to display code in a proportional font, they can readily
> use \(aq and \(ga to get ASCII ' and ` printed.
>
> > So in all seriousness, we should be revising our man pages to produce
> > better-looking monospaced output. Have you tried viewing your average
> > man(7) user's "EXAMPLES" section as PostScript? It's rarely pretty
> > because authors don't care about switching between proportional and
> > constant-width typefaces. After all, why *would* you if you only care
> > about terminal output?
>
> While your argument makes sense, note that part of the infrastructure
> already *is* in place:
>
>  * In man(7) - or more precisely, in man-ext - the .EX macro
>already does .do fam C .
>  * In mdoc(7), .Bd -literal .Dl .Li .Ql .Dv .Er .Ev
>already do .nop \*[doc-Li-font]\c
>which is \f[C] in troff mode and \f[R] in nroff mode
>
> > Currently, \f(CW is meaningless in -Tutf8 or -Tascii output, but it could
> > very well be exploited to know which quotes are appropriate to remap, and
> > what portions of an author's document to keep our grubby meathooks off
> of.
>
> From a user's perspective, that does make sense to me.
>
> A different way to talk about it, maybe more clearly, would be to talk
> about a "literal mode", which would have two distinct effects:
>
>  * set ASCII characters verbatim, even ' - ^ ` ~
>with the only exception of \ which still needs to be \e or \[rs]
>  * use a fixed-width font
>
> What do you think?
> Is that logically sound, and is it feasible?
> In mandoc, it is clearly feasible.
>
> It also seems manageable from the perspective of maintaining large
> collections of manual pages, and it will definitely improve average
> typographic quality.
>

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

[John Gardner]

I think it's time we took constant-width fonts seriously when preparing
output for the terminal. Here me out on this:

You see, I've never, *ever* needed fancy typography when typesetting code
samples, which are invariably set in a fixed-pitch (monspace) typeface. The
use of a fixed-pitch font stipulates the author's expectation that that
verbatim input should *stay* verbatim. On the other hand, nobody in their
right mind would deliberately write source-code in a proportional typeface,
so we can trust the use of Georgia or Helvetica to indicate body text—stuff
for reading and styling.

So in all seriousness, we should be revising our man pages to produce
better-looking monospaced output. Have you tried viewing your average
man(7) user's
"EXAMPLES" section as PostScript? It's rarely pretty because authors don't
care about switching between proportional and constant-width
typefaces. After all, why *would* you if you only care about terminal
output?

Currently, \f(CW is meaningless in -Tutf8 or -Tascii output, but it could
very well be exploited to know which quotes are appropriate to remap, and
what portions of an author's document to keep our grubby meathooks off of.

On Mon, 2 Nov 2020 at 22:09, Ingo Schwarze  wrote:

> Hi,
>
> Werner LEMBERG wrote on Mon, Nov 02, 2020 at 09:42:35AM +0100:
>
> > To summarize: It seems that there is only a single platform left today
> > that by default uses a bitmap font for terminals with symmetric ` and
> > ' characters.  This sort-of proves my point, doesn't it?
>
> I fear you missed the point.  What matters is that large numbers
> of manual pages use unescaped ' and ` to represent plain ASCII '
> and ` for programming language syntax documentation - because that
> has been supported in manual pages for more than a decade, because
> authors have become used to it, and because it seems likely that
> before 2008, not many people ever considered mon-ASCII output of
> manual pages.  So dropping support now gratuitiously breaks formatting
> of large numbers of manual pages in an important way, changing all
> existing pages would be a huge make-work project, and attempting
> to re-educate programmers is likely to alienate many of them.
>
> The shape of glyphs in some fonts has nothing to do with the issues
> involved.
>
> Admittedly, Jan could have chosen a less misleading example.  From
> the context of his mail, it appeared that he intended `that' as
> "ASCII backtick quote apostophe-quote" (even though that is
> ungrammatical in most programming languages i'm aware of), not as
> "that in single quotes".  An example like
>
>   my_var=`sed 's/foo/bar/g' input.txt`
>
> would have been less confusing.
>
> Yours,
>   Ingo
>

Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

[John Gardner]

>
> To summarize: It seems that there is only a single platform left today
> that by default uses a bitmap font for terminals with symmetric ` and
> ' characters.  This sort-of proves my point, doesn't it?


It gets even worse. See, whenever you edit source code, symmetric
quote-pairs look like a directional pair of quotes facing the wrong way:

[image: VirtualBox_Solaris 11.3_02_11_2020_20_09_16.png]

Obviously, these letterforms made sense back when
electromechanical typewriters were still a thing, and terminals didn't need
emulation. But... not in 2020... :\

On Mon, 2 Nov 2020 at 19:42, Werner LEMBERG  wrote:

>
> > It's called Sun Gallant Demi
>
> Thanks.
>
> > (or simply "Gallant", as no other weights or variations of it
> > exist). It's the default console font of SPARC workstations and
> > SunOS/Solaris;
>
> OK.
>
> > OpenBSD used to use it, until they switched to a much blander
> > console font .
>
> Not my taste... – additionally, ` and ' are no longer symmetric.
>
> > It's the only fixed-pitch serif typeface I've seen that pulls that
> > look off naturally.
>
> To summarize: It seems that there is only a single platform left today
> that by default uses a bitmap font for terminals with symmetric ` and
> ' characters.  This sort-of proves my point, doesn't it?
>
>
> Werner
>