Re: Doubts about a typo fix

[Paul Eggert]

On 2022-11-26 13:56, G. Branden Robinson wrote:


A lot of the pieces are in place to make this work (Deri and I have
wrangled over gropdf's diagnostic messages in this very area, but I
think we reached consensus :D ), but it needs integration testing under
multiple scenarios.


In the meantime I filed an Ubuntu bug here:

https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1998031

Unfortunately I don't have an Ubuntu 22.10 host that's public. The GCC 
Compile Farm has a 22.04 host; perhaps that's good enough.




I believe Solaris troff to be fossilized


Yes and no. Solaris 10 is no longer supported after January 2024, so if 
it and all the other traditional troffs die out by 2024 we can stop 
worrying about this then.


Solaris 11.4, the only Oracle Solaris version that is planned to be 
supported after January 2024, is based on groff 1.22.3 instead of on 
traditional troff. See:


https://docs.oracle.com/cd/E88353_01/html/E37839/troff-1.html
https://www.illumos.org/issues/12692


Oh, and one more thing. And this is relevant to TZDB! Ubuntu's groff 
ignores the TZ environment variable; see:


https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1908333

This is apparently due to Ubuntu's reproducible-build folks going off 
the deep end. For example, on Ubuntu 22.10:


$ echo $TZ; date; echo '\n[year]-\n[mo]-\n[dy] 
\n[hours]:\n[minutes]:\n[seconds]' | groff -Tascii | grep .


Sat Nov 26 18:30:29 PST 2022
2022-11-27 2:30:29

I hope upstream groff never does this

Re: Doubts about a typo fix

[Deri]

On Saturday, 26 November 2022 21:56:04 GMT G. Branden Robinson wrote:
> Deri, can you help me come up with a list of things that will break when
> running ps2pdf over a PostScript document?  PDFs produced that way will
> have no CMap.  What will happen to PS documents that use the SS or ZDR
> fonts?  Will anything to do with paper format or orientation be
> affected?

I think Peter has a section in the using mom for pdfs documentation.

Cheers

Deri

Re: using the SS (slanted symbol) font with gropdf

[Deri]

On Saturday, 26 November 2022 20:23:22 GMT G. Branden Robinson wrote:
> This is probably of most interest to Deri but I thought I'd send it to
> the list.
> 
> This is kind of a follow-up to a message from July.
> 
> https://lists.gnu.org/archive/html/groff/2022-07/msg00145.html
> 
> I'm playing with using the PostScript slanted symbol font ("SS") with
> gropdf.


Hi Branden,

I have looked at the SS font now.

It is not included in devpdf because symbolsl.pfa is not a type 1 postscript 
font! It is a postscript program which generates a font when run by a 
postscript interpreter. The gropdf man page does say you can only use it with 
type 1 fonts. If you view the file you will see it is significantly different 
from other pfa files on your system.

I don't think it is unreasonable for gropdf to barf over its contents, and 
viewers to barf as well. A reasonable error message when consuming a non type 
1 file would be desirable. :-)

Cheers 

Deri

Re: using the SS (slanted symbol) font with gropdf

[Alexis]

"G. Branden Robinson"  writes:

evince also complains.  Apart from the usual handful of 
Gtk-WARNING and
Gtk-CRITICAL diagnostics, because cool kids like GNOME 
developers never
look at the standard error stream ("terminal window?  what would 
I need

that for?"), I get this.

some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed

One might, at this point, begin to appreciate why I'm such a 
cranky old

bastard about diagnostic messages being informative.


As a cranky old bat on this topic myself, i just had to take a few 
minutes to find the source of this effort to further lower the bar 
of error message quality. It turns out it's coming from Poppler, 
not Evince, in CairoFontEngine.cc:


   fprintf(stderr, "some font thing failed\n");


Alexis.

Re: [PATCH v2 3/4] zic.8: Use correct escape sequences instead of special characters

[Paul Eggert]

On 2022-11-26 13:19, G. Branden Robinson wrote:

I would attach scans of Tables I and II from "NROFF/TROFF User's
Manual", the version dated 1976, published with Volume 2 of the Unix
Programmer's Manual (1979)


Thanks for looking into this. It took me a trip down memory lane as I 
believe I was the first person to submit a computer-typeset PhD thesis 
to UCLA. I used 7th Edition Unix troff along with the C/A/T 
phototypesetter that was troff's main target in the 1970s. (As an aside, 
the C/A/T was why stderr was invented; see Diomidis Spinellis's "The 
Birth of Standard Error" 2013-12-11 
.)


Solaris 10 /usr/bin/troff is largely unchanged from 1970s troff, and 
supports \(ga but none of the other escapes you mention, I expect 
because they were not present in the Bell Labs special font version 4 
and Commercial II that Unix assumed on the C/A/T. The source code of 7th 
Edition Unix troff agrees with Solaris 10 behavior here, and this also 
agrees with 7th Edition Unix /usr/doc/troff/table2 which documents \(ga 
but none of the other escapes you mentioned. I'm a bit surprised that 
the printed manuals you mention disagree with 7th Edition Unix, but 
anyway it doesn't matter all that much since Solaris 10 is what it is.


On other words, on Solaris 10 if I take this file 'foo':

.nf
default font
aq |\(aq| |'|
ga |\(ga| |`|
ha |\(ha| |^|
ti |\(ti| |~|
.ft CW
CW font
aq |\(aq| |'|
ga |\(ga| |`|
ha |\(ha| |^|
ti |\(ti| |~|

and run the shell command:

   /usr/bin/troff foo | /usr/lib/lp/postscript/dpost >foo.ps

I get the attached file foo.ps, and 'evince' says only \(ga works and 
even there it's barely usable in the default font, as shown in the 
attached screenshot foo.png of 'evince' displaying foo.ps.




.ie \n(.g .q \f(CR!$%&\(aq()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti\fP .
.el .ie t .q \f(CW!$%&'()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti\fP .
.el   .q !$%&'()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti .


With Solaris 10 in mind, in the second line of your proposed code the 
\f(CW...\fP and the \(ga are OK but the \(ha, \(ga, \(ti are dubious so 
I installed the attached patch instead.

foo.ps
Description: PostScript document
From 897c2968f128b7854a486405bb68666265b38b24 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 26 Nov 2022 15:44:18 -0800
Subject: [PROPOSED] * zic.8: Work better with Solaris 10 troff.

---
 zic.8 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/zic.8 b/zic.8
index ccd012b3..019a289c 100644
--- a/zic.8
+++ b/zic.8
@@ -350,6 +350,7 @@ nor
 To allow for future extensions,
 an unquoted name should not contain characters from the set
 .ie \n(.g .q \f(CR!$%&\(aq()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti\fP .
+.el .ie t .q \f(CW!$%&'()*,/:;<=>?@[\e]^\(ga{|}~\fP .
 .el .q !$%&'()*,/:;<=>?@[\e]^`{|}~ .
 .TP
 .B FROM
-- 
2.37.2

Re: [tz] Doubts about a typo fix

[Russ Allbery]

"G. Branden Robinson"  writes:

> For what it's worth, groff and Heirloom doctools nroff don't print
> "something else" in bold (this is true even in Heirloom's default, _not_
> groff compatibility, mode), and DWB 3.3 nroff does.

Oh, incidentally, I ran into what felt to me like a bug in groff that I
think has been there for a while.  Two people noticed it within a month,
but I think the bug has been around for quite a while.

The new comment in Pod::Man largely explains it:

# Originally, this function was much simpler because it went directly from \fB
# to \f(CW and relied on \f(CW clearing bold since it wasn't \f(CB.
# Unfortunately, while this works for mandoc, this is not how groff works;
# \fBfoo\f(CWbar still prints bar in bold.  Therefore, we force the font back
# to the default before each font change.

This sadly results in some rather tedious font manipulation in Pod::Man,
although most of the font complexity is still due to the Solaris bug.

I'm guessing that \f(CR would have cleared bold, and \f(CW doesn't because
it's weird and special, and that's why this isn't a bug?

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

Re: [tz] Doubts about a typo fix

[Russ Allbery]

"G. Branden Robinson"  writes:

> It's my lucky day!  I've been meaning to buttonhole you for quite some
> time regarding my man(7) reforms and pod2man's output.

I just made another major release, so on the plus side my brain is fully
up to speed with the source, but on the minus side, I'm also a little
tired of working on it.  :)  But, anyway, do tell!

I have some very old mail about better compatibility with the output for
mandoc's HTML conversion sitting around somewhere that I need to respond
to as well.

The standard problem is that I'm still trying to stick as much as possible
to my mission of producing portable *roff, but testing on anything other
than recent Debian with groff is tedious and annoying, so I mostly try not
to change things unless there's an obvious bug.

> For what it's worth, groff and Heirloom doctools nroff don't print
> "something else" in bold (this is true even in Heirloom's default, _not_
> groff compatibility, mode), and DWB 3.3 nroff does.

Yes, I think this bug is specific to Solaris, although it was still
present in Solaris 11.

> Any other fonts, a document needs to test for and be programmed
> defensively regarding.[3]  (It's okay to give up with ".ab".)

Pod::Man uses B, I, CW, CB, and CI only.  (To be honest, part of me is
very tempted to drop the C* typefaces because they're quite annoying to
deal with and the cause of a bunch of bugs, and I'm dubious enough people
still use troff to make it worth the effort, but apparently the HTML
converters may use them and in theory they work now.  So I have left them
alone.)

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

Re: [tz] Doubts about a typo fix

[G. Branden Robinson]

[dropping everyone but Russ and the groff list]

Hi Russ,

It's my lucky day!  I've been meaning to buttonhole you for quite some
time regarding my man(7) reforms and pod2man's output.

I had notions of trying to get you into a sort of informal summit
meeting at DebConf 20 but a lot of people got sick.  That's how we know
that God Himself didn't want that conference to be held in Israel.

At 2022-11-25T19:20:37-0800, Russ Allbery wrote:
> \fBsomething\fP \f(CW-\fP something else
> 
> you will discover that "something else" is in bold because the second
> \fP reverts to the "previous" font, which nroff thinks is \fB becuase
> \f(CW was ignored.  (Just tested now on a Solaris 10 host.)  Pod::Man
> has fairly elaborate workarounds for this bug.

For what it's worth, groff and Heirloom doctools nroff don't print
"something else" in bold (this is true even in Heirloom's default, _not_
groff compatibility, mode), and DWB 3.3 nroff does.

> Just be warned that \f(CR is not a valid font name in all *roff
> implementations,

Even if it's a valid font name in an _implementation_, it may not be for
any particular output device.  Because CW is a popular name, groff
aliases it to an available font on most of its output devices.

And, in case anyone was wondering, "CW" and "CWI" are bona fide
typefaces on groff's "dvi" device, because TeX's Computer Modern font
collection has them.  But there's no "CWB" or "CWBI", so groff (Git)
remaps those to CW faces of normal weight.

If I could legislate matters for the *roff universe I'd say every
implementation needs to recognize the 12 text faces of PostScript Level
1.  That's the Cartesian product of the families T, C, and H ("Times",
"Courier", and "Helvetica"[1]) and the styles roman, italic, bold, and
bold-italic, and do a best-effort rendering in a serif, monospaced, or
sans serif typeface (respectively) if you're a typesetter, and just the
style if you're not.  Practically speaking, man pages can even do
without sans serif, but *roff is for more than just man pages.  And if
you're fond of certain of Kernighan's old books you might like to see a
bold sans serif face for (sub)section headings anyway.[2]

Any other fonts, a document needs to test for and be programmed
defensively regarding.[3]  (It's okay to give up with ".ab".)

> which is why Pod::Man uses \f(CW by default.  Not sure how much you
> care.  (And, to be honest, not sure how much anyone should care about
> any implementations other than groff and mandoc these days.)

Speaking of mandoc, has anyone seen Ingo lately?

Regards,
Branden

[1] Trademark holders didn't see me write those.

[2] About 20 years ago groff tried to add a feature for this, a "header
font" string, HF, but it didn't work because it unconditionally set
HF to "B" instead of only doing so if HF was not already defined.
But it will work in the next release: "groff -dHF=HB -man".  In
groff 1.23 you'll even get bold italics in a bold section heading if
you ask for italics.

[3] This would be tedious in AT&T troff but--this is Sparta!--you could
write a macro for it.  The idea is to copy the .f register, select
the new face, and then see if .f changed.  If it didn't, the font
is not available.  (You might as well work around DWB/Solaris
troff's previous-font clobberific behavior while you're copying .f.)
In groff, naturally, you can ".if F fontname".


signature.asc
Description: PGP signature

Re: Doubts about a typo fix

[G. Branden Robinson]

[dropping Paul, Alex, and tz@iana]

At 2022-11-26T22:20:23+0100, Steffen Nurpmeso wrote:
> It would be great if groff would release adjustments to grotty so
> that one could again use copy+paste also in manuals.

One can.

> And now please do not beat me onto that hyphen-minus for options, and
> that one should do this or that, but it is for many other characters,
> too.  If i look at bash manual for example, hyphen-minus is ok, but
> caret is not ^ but U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT, and i see
> U+2018 LEFT SINGLE QUOTATION MARK instead of single-quotes.

Those mean ^ was typed when \(ha was meant, and ` was typed when \(ga
was meant.

> That is cool and maybe milks the shit out of the typographic
> capabilities of modern UTF-8 terminal emulators (i think i quote you
> here, more or less),

I don't think so.  When I milk something I emphatically do not
anticipate the production of excrement from the orifice.

I try to keep my cruder wise cracks off of mailing lists.

> but i always have to use "LC_ALL=C man XY" to enable copy+paste for
> myself.

That's not necessary.  You can employ the workaround documented in the
PROBLEMS file, as I believe I have told you before.

---snip---
* When viewing man pages, some characters on my UTF-8 terminal emulator
  look funny or copy-and-paste wrong.  Why?

Some Unicode Basic Latin ("ASCII") input characters are mapped to
non-Basic Latin code points in output for consistency with other output
devices, like PDF.  See groff_man_style(7) and groff_char(7) for correct
input conventions and background.  If you use the correct groff special
character escape sequences to input them, you will get correct output no
matter what device the input is formatted for.

However, many man pages are written in ignorance of the correct special
characters to obtain the desired glyphs.  You can conceal these errors
by adding the following to your site-local man(7) configuration.  The
file is called "man.local"; its installation directory depends on how
groff was configured when it was built.

--- start ---
.if '\*[.T]'utf8' \{\
.  char ' \[aq]
.  char - \-
.  char ^ \[ha]
.  char ` \[ga]
.  char ~ \[ti]
.\}
--- end ---

You may also wish to do the same for "mdoc.local".
---snip---

You can edit one file (or two, if you care about mdoc(7) pages), one
time, and never have to worry about typing LC_ALL=C before your man
commands again.

> But hey, it is only me, i am not a prof at an University who is prowd
> of dozens of Noble price winners and other such prices, many of them
> still worth something aka based upon scientific grounds.

I don't know who you're aiming at with this status-oriented gripe, but
it doesn't sound like me.  I am relatively unlettered person,
academically (can't you tell?).  I enjoy university classes but I'm not
good at being graded.  😅

Regards,
Branden


signature.asc
Description: PGP signature

Re: Doubts about a typo fix

[G. Branden Robinson]

Hi Paul!

At 2022-11-26T13:01:58-0800, Paul Eggert wrote:
> [taking t...@iana.org off the cc as this isn't particularly time zone
> relevant any more]

Fair point.

> With the same input (that is, with the last line being "Copy and paste
> me: \f(CRfoo\-bar-baz\fP." and the same commands on Ubuntu 22.10, I
> get the attached, where the symbols are unfortunately
> indistinguishable visually.

I see what you mean and, yes, that is awful.  If I had to bet, I'd wager
that they really are rendering as the same glyph, possibly because
someone is remapping - to \- in man pages.  Many bad decisions like this
have been taken by people who have to deal with enraged man page readers
at terminals who never, ever use groff for real typesetting.  Both
audiences can be served but some care is required.

If someone has an Ubuntu 22.10 shell account they could offer me for a
brief period, I'd be happy to look around to see if I can root-cause it.

> If I instead use -P-e as Deri suggested, then I see this:
> 
>   $ groff -Tpdf -P-e -man minus-and-hyphen.man >t-e.pdf
>   Failed to open
> '/usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular'
> 
> so I'm in font-installation purgatory. I have Ubuntu's gsfonts package
> installed, but there is no file
> /usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular; instead
> there's a file
> /usr/share/ghostscript/9.56.1/Resource/Font/NimbusRoman-Regular. Presumably
> this is a configuration screwup on the Ubuntu side, as
> /usr/share/groff/1.22.4/font/devpdf/download is full of references to
> /usr/share/ghostscript/9.55.0/ but has no references to 9.56.1 which is what
> is installed.
> 
> I assume this is an Ubuntu bug? Should someone file a bug report? At
> any rate it's not a good situation.

No indeed it is not.  This is a recurring, painful gap with
groff-as-packaged-by-distributors.[1]  Basically, something like a
"package trigger" is required to regenerate the "download" file that
gropdf uses to tell it where to find font files for embedding, not when
groff is upgraded, but when _gsfont_ (or whatever is providing the Type
1 PostScript fonts from the URW foundry) is upgraded.  groff doesn't
install a tool to help with this, though there is one called
BuildFoundries in our source tree, and even if we did, distributors
would need to add the requisite trigger(s) to packages that _aren't_
groff.

Deri has been leaning on me to make BuildFoundries a real tool that we
ship but I think there's more work to do than I can squeeze in before
Debian bookworm freezes, and that's my calendar target.  Among other
issues that need to be dealt with is the _disappearance_ of the URW
fonts.  That is, if someone has both groff and gsfonts installed, then
removes gsfonts, the the gropdf command should react
intelligently/helpfully the next time it is run (perhaps warning that
fonts can't be embedded).  There's no reason to force groff to depend on
gsfonts, not for gropdf's sake, and certainly not otherwise.  Some
distributors segregate gropdf into a "groff-perl" package because that
program is written in Perl.

A lot of the pieces are in place to make this work (Deri and I have
wrangled over gropdf's diagnostic messages in this very area, but I
think we reached consensus :D ), but it needs integration testing under
multiple scenarios.

> Ah, I guess my problem is that I was using ps2pdf, i.e.:
> 
>   groff samp.1 >samp.ps
>   ps2pdf samp.ps samp.pdf

Ah, whoops.

> So I suppose I should use 'groff -Tpdf' (which I had forgotten about)
> rather than groff + ps2pdf. Presumably others make the same mistake I
> do, though

Yes.  I'm not sure where the best place for this cautionary note is.
Not in gropdf(1), because the people who most need to know this won't
ever think to look there.  grops(1) seems appropriate but since most
people don't run that command directly that also seems insufficient.  A
brief warning in groff(1) similar to the one we have regarding
grotty(1), SGR escape sequences, and pagers as well might do the trick.

Deri, can you help me come up with a list of things that will break when
running ps2pdf over a PostScript document?  PDFs produced that way will
have no CMap.  What will happen to PS documents that use the SS or ZDR
fonts?  Will anything to do with paper format or orientation be
affected?

> Anyway, when I run "groff -Tpdf samp.1 >samp-better.pdf", cut and
> paste now works as expected, which is good.

Excellent!

> > I'm curious to know what that support looks like.  Is there evidence
> > of any _development_?
> 
> At this point it's just Solaris bug fixes, mostly security. The latest
> patches installed on our department's Solaris 10 server are dated four
> weeks ago (patches to libz). None of this affects traditional troff;
> /usr/bin/troff is dated 2005.

I believe Solaris troff to be fossilized, and given the barriers present
to contribution to Illumos, on top the unsexiness of *roff compared to,
say, ZFS, I don't expect much more motion from the

Re: Doubts about a typo fix

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221126035253.pli53qzgfx6tbax5@illithid>:
 |At 2022-11-25T18:18:46-0800, Paul Eggert wrote:
 ...
 |> If we did that, Groff would set a source string like "\*-\*-help" as
 |> "−−help", with two instances of U+2212 MINUS SIGN instead of U+002D
 |> HYPHEN-MINUS. Therefore people couldn't cut and paste code examples
 |> out of HTML or PDF, and into the shell.
 |
 |This hasn't been true for PDFs produced by groff for about 10
 |years.[1][2]  You can copy a U+2212 minus sign and it will paste as a
 |U+002D.

It would be great if groff would release adjustments to grotty so
that one could again use copy+paste also in manuals.  And now
please do not beat me onto that hyphen-minus for options, and that
one should do this or that, but it is for many other characters,
too.  If i look at bash manual for example, hyphen-minus is ok,
but caret is not ^ but U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT,
and i see U+2018 LEFT SINGLE QUOTATION MARK instead of
single-quotes.  That is cool and maybe milks the shit out of the
typographic capabilities of modern UTF-8 terminal emulators (i
think i quote you here, more or less), but i always have to use
"LC_ALL=C man XY" to enable copy+paste for myself.  But hey, it is
only me, i am not a prof at an University who is prowd of dozens
of Noble price winners and other such prices, many of them still
worth something aka based upon scientific grounds.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [PATCH v2 3/4] zic.8: Use correct escape sequences instead of special characters

[G. Branden Robinson]

Hi Paul,

At 2022-11-25T18:31:02-0800, Paul Eggert wrote:
> On 2022-11-23 10:43, Paul Eggert wrote:
> > I installed that
> Further testing showed that the installed patch doesn't work with
> traditional troff, which doesn't support groff escape sequences like
> \(aq.

I think this patch goes too far in the retrograde direction.

\(xx, where xx is any two characters, is not a groff extension.  It
comes from Ossanna troff all the way back in the mid-1970s.

It is a special character escape sequence; a groff way of spelling it
is \[xxx] where xxx can be of any nonzero length (but cannot contain a
closing square bracket).

The repertoire of supported special character identifiers varies by
implementation and, after Kernighan's rewrite of troff circa 1980 for
device-independence, by output device.  Nevertheless, for
portability/backward compatibility, a set of them are very widely
supported.  These include three that your patch takes out, \(ha, \(ga,
and \(ti.  Replacing these with ASCII characters will _not_ produce
correct typography on typesetting output devices.

I would attach scans of Tables I and II from "NROFF/TROFF User's
Manual", the version dated 1976, published with Volume 2 of the Unix
Programmer's Manual (1979), and reprinted by Holt, Reinhart, and Winston
in 1983, but the linux-man list rejects all attachments bigger than a
breadbox, so I will ask for your trust (or ask me for it privately).

Those tables illustrate the glyph repertoire of Ossanna troff and the
special character identifiers that were implemented.

groff_char(7) from groff 1.22.4 and earlier marks the special character
identifiers you can expect to be portable (with "***" in its listings),
and for 1.23 I have added a "History" section to the page which
addresses most of the thousand questions I've asked over the past few
years while trying to learn this stuff.  I'll put that in a footnote.[1]

> To fix this I installed the equivalent of the attached further patch to
> TZDB.

I therefore propose the following snippet instead, also taking into
account Solaris 10 troff's poor handling of unsupported font selections
in nroff.

.q + .
To allow for future extensions,
an unquoted name should not contain characters from the set
.ie \n(.g .q \f(CR!$%&\(aq()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti\fP .
.el .ie t .q \f(CW!$%&'()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti\fP .
.el   .q !$%&'()*,/:;<=>?@[\e]\(ha\(ga{|}\(ti .
.TP
.B FROM
Gives the first year in which the rule applies.

What do you think?

Regards,
Branden

[1] (Much UTF-8 follows.)

History
A consideration of the typefaces originally available to AT&T nroff
and troff illuminates many conventions that one might regard as
idiosyncratic fifty years afterward.  (See section “History” of
roff(7) for more context.)  The face used by the Teletype Model 37
terminals of the Murray Hill Unix Room was based on ASCII, but
assigned multiple meanings to several code points, as suggested by
that standard.  Decimal 34 (") served as a dieresis accent and
neutral double quotation mark; decimal 39 (') as an acute accent,
apostrophe, and closing (right) single quotation mark; decimal 45
(-) as a hyphen and a minus sign; decimal 94 (^) as a circumflex
accent and caret; decimal 96 (`) as a grave accent and opening
(left) single quotation mark; and decimal 126 (~) as a tilde accent
and (with a half‐line motion) swung dash.  The Model 37 bore an
optional extended character set offering upright Greek letters and
several mathematical symbols; these were documented as early as the
kbd(VII) man page of the (First Edition) Unix Programmer’s Manual.

At the time Graphic Systems delivered the C/A/T phototypesetter to
AT&T, the ASCII character set was not considered a standard basis
for a glyph repertoire by traditional typographers.  In the stock
Times roman, italic, and bold styles available, several ASCII
characters were not present at all, nor was most of the Teletype’s
extended character set.  AT&T commissioned a “special” font to
ensure no loss of repertoire.

A representation of the coverage of the C/A/T’s text fonts follows.
The glyph resembling an underscore is a baseline rule, and that
resembling a vertical line is a box rule.  In italics, the box rule
was not slanted.  We also observe that the hyphen and minus sign
were already “de‐unified” by the fonts provided; a decision whither
to map an input “-” therefore had to be taken.

   ┌┐
   │A B C D E F G H I J K L M N O P Q R S T U V W X Y Z │
   │a b c d e f g h i j k l m n o p q r s t u v w x y z │
   │0 1 2 3 4 5 6 7 8 9 fi fl ffi ffl   │
   │! $ % & ( ) ‘ ’ * + - . , / : ; = ? [ ] │   │
   │• □ — ‐ _ ¼ ½ ¾ ° † ′ ¢ ® © │
   └┘

The special font s

Re: Doubts about a typo fix

[Paul Eggert]

[taking t...@iana.org off the cc as this isn't particularly time zone 
relevant any more]


On 2022-11-25 19:52, G. Branden Robinson wrote:



If I prepare the following document:

$ cat EXPERIMENTS/minus-and-hyphen.man
.TH foo 1 2022-11-25 "groff test suite"
.SH Name
foo \- frobnicate a bar
.SH Description
Copy and paste me: foo\-bar-baz.

and render it with "groff -Tpdf -man" using either groff 1.22.4 or groff
Git, then when I copy-and-paste "foo-bar." from the document to a shell
prompt,...
behavior I'm familiar with.  I find the minus sign and hyphen glyphs
fairly distinguishable.  I modified my example file above to switch to
the CR font.  Attaching (cropped, 7.7KiB) screenshot.


With the same input (that is, with the last line being "Copy and paste 
me: \f(CRfoo\-bar-baz\fP." and the same commands on Ubuntu 22.10, I get 
the attached, where the symbols are unfortunately indistinguishable 
visually. If I instead use -P-e as Deri suggested, then I see this:


  $ groff -Tpdf -P-e -man minus-and-hyphen.man >t-e.pdf
  Failed to open 
'/usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular'


so I'm in font-installation purgatory. I have Ubuntu's gsfonts package 
installed, but there is no file 
/usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular; instead 
there's a file 
/usr/share/ghostscript/9.56.1/Resource/Font/NimbusRoman-Regular. 
Presumably this is a configuration screwup on the Ubuntu side, as 
/usr/share/groff/1.22.4/font/devpdf/download is full of references to 
/usr/share/ghostscript/9.55.0/ but has no references to 9.56.1 which is 
what is installed.


I assume this is an Ubuntu bug? Should someone file a bug report? At any 
rate it's not a good situation.



>> If we did that, Groff would set a source string like "\*-\*-help" as
>> "−−help", with two instances of U+2212 MINUS SIGN instead of U+002D
>> HYPHEN-MINUS. Therefore people couldn't cut and paste code examples
>> out of HTML or PDF, and into the shell.
>
> This hasn't been true for PDFs produced by groff for about 10
> years.[1][2]  You can copy a U+2212 minus sign and it will paste as a
> U+002D.

Ah, I guess my problem is that I was using ps2pdf, i.e.:

  groff samp.1 >samp.ps
  ps2pdf samp.ps samp.pdf

So I suppose I should use 'groff -Tpdf' (which I had forgotten about) 
rather than groff + ps2pdf. Presumably others make the same mistake I 
do, though


Anyway, when I run "groff -Tpdf samp.1 >samp-better.pdf", cut and paste 
now works as expected, which is good.



>> For the
>> latter I test with /usr/bin/nroff and /usr/bin/troff on Solaris 10,
>> which is the oldest troff I know that is still supported.
>
> I'm curious to know what that support looks like.  Is there evidence of
> any _development_?

At this point it's just Solaris bug fixes, mostly security. The latest 
patches installed on our department's Solaris 10 server are dated four 
weeks ago (patches to libz). None of this affects traditional troff; 
/usr/bin/troff is dated 2005.

Re: [tz] Doubts about a typo fix

[G. Branden Robinson]

At 2022-11-25T19:50:14-0800, Paul Eggert wrote:
> On 2022-11-25 19:20, Russ Allbery wrote:
> > You have to be very careful with the combination of \f(CW and \fP on
> > Solaris 10 nroff
> 
> That should be OK, as \f(CW - which is now \f(CR - is used only if
> \n(.g is nonzero, i.e., only if it's groff and not traditional troff.

Just for precision's sake, the .g register interpolating a true value
means (by convention) that an implementation is claiming support for
groff extensions.

This happens with Heirloom Doctools troff, for instance, if one gives it
the "-mg" option.  (There are other ways to switch on its "groff mode".)

Also, to reiterate, "CW" as a font name is not a groff extension; it has
some history in Documenter's Workbench troff and I think it may have
appeared in Research Unix troff as well in the 1980s, but I don't have
convincing evidence of this, just educated guesses based on man(7) and
ms(7) man pages from that era.  If I had sources for Research Unix
V8-V10 I'd be a happy guy.

> I toyed with using \f[CW] instead of \f(CW to underscore that it's
> groff-specific. However, that might be overkill given the number of
> non-*roff programs that read these files.

In my opinion that's not necessary, and implies too much.

Regards,
Branden


signature.asc
Description: PGP signature

using the SS (slanted symbol) font with gropdf

[G. Branden Robinson]

This is probably of most interest to Deri but I thought I'd send it to
the list.

This is kind of a follow-up to a message from July.

https://lists.gnu.org/archive/html/groff/2022-07/msg00145.html

I'm playing with using the PostScript slanted symbol font ("SS") with
gropdf.

Here's my input document.

$ cat EXPERIMENTS/slanted-symbols.ms
.LP
Let's demonstrate use of the
.B S
and
.B SS
fonts in PDF.
.LP
Symbol:
.ft S
\(*A \(*B \(*C \(*a \(*b \(*c
.ft
.LP
Slanted Symbol:
.ft SS
\(*A \(*B \(*C \(*a \(*b \(*c
.ft

(Classical studies majors need not tell me that I should have said "G"
instead of "C".  I noticed that as soon as the document rendered.)

I used groff 1.22.4 (Debian) to produce a PDF, contriving an extra font
description directory to force gropdf to find the SS font.

$ mkdir ~/tmp/devpdf
$ cp -l /usr/share/groff/1.22.4/font/devps/SS ~/tmp/devpdf
$ groff -ms -F ~/tmp -Tpdf EXPERIMENTS/slanted-symbols.ms >| ss.pdf

The lowercase Greek letters are slanted in both the S and SS fonts; the
stroke weight seems heavier for the latter, but for me that's not a big
deal.

When I do the same with groff Git, I am a little more worried.

$ ./build/test-groff -ms -F ~/tmp -Tpdf EXPERIMENTS/slanted-symbols.ms >| ss.pdf
Use of uninitialized value $body in concatenation (.) or string at 
.../GIT/groff/build/gropdf line 2658, <__ANONIO__> line 38.
Use of uninitialized value $tail in concatenation (.) or string at 
.../GIT/groff/build/gropdf line 2658, <__ANONIO__> line 38.
Use of uninitialized value $fld in concatenation (.) or string at 
.../GIT/groff/build/gropdf line 2380, <> line 90.
Use of uninitialized value $fld in concatenation (.) or string at 
.../GIT/groff/build/gropdf line 2380, <> line 90.

But it gets better.  When I view the file with evince, none of the
lowercase Greek letters from the SS font render at all.

evince also complains.  Apart from the usual handful of Gtk-WARNING and
Gtk-CRITICAL diagnostics, because cool kids like GNOME developers never
look at the standard error stream ("terminal window?  what would I need
that for?"), I get this.

some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed
some font thing failed

One might, at this point, begin to appreciate why I'm such a cranky old
bastard about diagnostic messages being informative.

okular renders groff-Git-generated ss.pdf fine, and just like the
1.22.4-generated version to my eyeballs.

So I have two concerns.

1.  What can be done to hush up those Perl warnings?
2.  Is gropdf in groff Git producing some kind of ill-formed document
that okular is able to cope with but evince doesn't?

Actually, make it 3.

3.  I'd like to know if use of groff's SS font (for grops) is necessary
for any reason when using gropdf.  If not, then I think I would like
to update gropdf's man page to mention its superfluity.

Thanks for any light you can shed on this stuff.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Doubts about a typo fix

[Deri]

On Saturday, 26 November 2022 03:52:53 GMT G. Branden Robinson wrote:
> Some distributors do violence to the man.local file.  But I am not a PDF
> expert; for this I'll have to turn as I often do to Deri James, who also
> wrote the gropdf output driver.  Deri, what's a good way to root-cause
> the issue Paul describes?


Whenever there is a query about the "look" of a pdf it is important to rule 
out any vagaries in the particular fonts used by the pdf viewer used, so 
please repeat your tests adding "-P-e" to the command.

As regards the cut and paste of MINUS SIGN as a hyphen, this can be turned off 
by including -P-u as well. Note this will also affect the treatment of 
ligatures (ff/fi/ffi) in that cut and paste will not return them to their 
individual characters. It also affects string searching within the pdf, the 
troff input "\-b" would not be found by entering -b in the pdf viewer's search 
widget. Tested on Branden's minus-and-hyphen.man, with -P-u it finds -baz, 
without it finds both -bar and -baz.

Cheers 

Deri

Re: Unexpected behaviour when using linenumbering and tbl

[hbezemer--- via]

"G. Branden Robinson"  wrote:
Hi Tadziu and Branden,

Thanks for the quickfix Tadziu.
I've noted for myself to check the output of any preprocessor when trying to 
understand certain behaviour.

Branden thanks for sketching out the broader issue.
Being just an enduser, it's hard for me to give any useful advise.
Although from that enduser perspective I would argue that it should (at least) 
be clear what to expect when using linenumbering along with tbl or textblocks
(B1/B2 in mm also results in double linenumbering (using a diversion 
obviously).).

regards,

Hans


> Hi Hans,
> 
> At 2022-11-24T19:47:35+0100, hbezemer--- via wrote:
> > When I make exams I sometimes use linenumbering so I can refer to a
> > specific line of a source.  I noticed some unexpected behaviour when
> > having a table after the part that has linenumbers.  The table also
> > gets linenumbers added, which should not be the case of course.  I can
> > reproduce the behaviour with the example below.
> 
> Tadziu was swift to the rescue with good advice, so I'll cover the
> broader issue.
> 
> I think the formatter's line numbering feature and the tbl preprocessor
> interact in unexpected ways, and apparently always have.
> 
> First let me offer an example input and then I will show how it behaves
> with Unix Version 7 troff (1979), Heirloom Doctools troff (2019), groff
> 1.22.4 (2018) and groff Git HEAD.
> 
> $ cat ~/tmp/line-numbered-table.roff
> .nm 1
> Here is a line of output.
> Sic transit adispicing meatballs.
> Let's pad it out with more content to ensure the line breaks.
> .TS
> L.
> This is my table.
> There are many like it but this one is mine.
> T{
> My table is my best exhibit;
> I will guard it as I guard my life.
> Even as it requires multiple output lines for an entry.
> T}
> .TE
> What is the line number now?
> 
> Unix Version 7 on a SIMH PDP-11/45:
> 
>   1 Here is a line of  output.   Sic  transit  adispicing  meatballs.
>   2 Let's pad it out with more content to ensure the line breaks.
>   6 This is my table.
>   7 There are many like it but this one is mine.
>   8
>   9   3 My table is my best exhibit; I will guard it
>  10   4 as  I  guard  my  life.  Even as it requires
>  11   5 multiple output lines for an entry.
>  12 What is the line number now?
> 
> Heirloom Doctools troff:
> 
>   1 Here is a line of  output.   Sic  transit  adispicing  meatballs.
>   2 Let's pad it out with more content to ensure the line breaks.
>   6 This is my table.
>   7 There are many like it but this one is mine.
>   8
>   9   3 My table is my best exhibit; I will guard it
>  10   4 as  I  guard  my  life.  Even as it requires
>  11   5 multiple output lines for an entry.
>  12 What is the line number now?
> 
> groff 1.22.4:
> 
>   1 Here  is  a  line  of  output.  Sic transit adispicing meatballs.
>   2 Let’s pad it out with more content to ensure the line breaks.
>   6 This is my table.
>   7 There are many like it but this one is mine.
>   8   3 My table is my best exhibit; I will guard it
>   9   4 as  I  guard  my  life.  Even as it requires
>  10   5 multiple output lines for an entry.
> What is the line number now?
> 
> groff Git HEAD:
> 
>   1 Here  is  a  line  of  output.  Sic transit adispicing meatballs.
>   2 Let’s pad it out with more content to ensure the line breaks.
> This is my table.
> There are many like it but this one is mine.
>   3 My table is my best exhibit; I will guard it
>   4 as I guard my life.   Even  as  it  requires
>   5 multiple output lines for an entry.
> What is the line number now?
> 
> Observations:
> 
> 1.  I think the original behavior may have been considered buggy at
> Murray Hill.  I checked the entire corpus of Version 7's _Unix
> Programmer's Manual_, Volume 2, and could not find a single place
> where line numbering and tbl(1) tables were combined.  (I did this
> by scanning the pages visually and by grepping for `TS` calls and
> `nm` invocations.)
> 
> 2.  Heirloom Doctools troff seems quite faithful to its lineal ancestors
> of Ossanna troff and Lesk tbl.  Good!  That's less time I have to
> spend dealing with the painful Unix V7 TTY driver and the Spartan
> original Bourne shell.
> 
> 3.  Nevertheless these golden masters behave quite perversely when you
> set a text block in a table entry.  You get two sets of line
> numbers.  This is so perverse that I have to regard it as a bug.
> Anyone care to argue?
> 
> 4.  Also, the line numbers of the text block are counted before any
> preceding lines of the table, so the line numbers are not even
> monotonically increasing, let alone strictly increasing.  I find
> this incredibly dubious and hereby dare Ralph Corderoy to defend its
> correctness.
> 
> 5.  AT&T/Heirloom troff/tbl also seems to add unasked-for vertical space
> prior to the start of the table.  groff doesn't, and I don't think
> it should.  I looked briefly at the tbl output on Unix V7, but not
> long en