groff issue after upgrade to NetBSD-9.2

[Steve Blinkhorn]

This is on amd64, but I doubt that that's relevant.

I have an extensive collection of fonts for PostScript, so
/usr/share/groff_font/devps is a symbolic link to a /fonts directory. It
has been so since NetBSD-1.x and before that on BSD/OS and before that
into the mists of time.

I upgraded to NetBSD-9.2 several days ago, and suddenly my standard
document formats come out all wrong. The glyphs for the
variously-acquired (e.g. bought from Linotype) fonts do not seem to be
available, and the font metrics are wrong for the glyphs that do
appear.

I have a practical solution for the moment: if I mount_nfs a backup
copy of the same fonts directory on a remote server and point
groff_font/devps at that instead, everything goes back to normal.

Anyone have any insight into why migrating from 7.0 to 9.2 might cause
such a problem?

[Steve Blinkhorn]

Answer:

Unpacking the textproc set overwrites files like
/usr/share/groff_font/devps/DESC and devps/download, and maybe other
files which have been adapted or expanded locally. The unpacking
process follows any symbolic link that devps has been set to rather
than overwriting the symbolic link with a hard directory. Fortunately
I have backups. Would this not be worth a warning in the installation
guide - it's a similar issue to /etc, where precious lolcalisations
risk being lost?

I know thered is a move not to includee groff etc. in the main
distribution, but some of us use it extensively: I have substantial
software systems which emit *roff source files, it's not just a
manpage generator.

--

Post by Steve Blinkhorn
This is on amd64, but I doubt that that's relevant.
I have an extensive collection of fonts for PostScript, so
/usr/share/groff_font/devps is a symbolic link to a /fonts directory. It
has been so since NetBSD-1.x and before that on BSD/OS and before that
into the mists of time.
I upgraded to NetBSD-9.2 several days ago, and suddenly my standard
document formats come out all wrong. The glyphs for the
variously-acquired (e.g. bought from Linotype) fonts do not seem to be
available, and the font metrics are wrong for the glyphs that do
appear.
I have a practical solution for the moment: if I mount_nfs a backup
copy of the same fonts directory on a remote server and point
groff_font/devps at that instead, everything goes back to normal.
Anyone have any insight into why migrating from 7.0 to 9.2 might cause
such a problem?
--

--
Steve Blinkhorn <***@prd.co.uk>

****************************************************************************
This email is for the addressee only. If you are not the addressee
you should immediately delete this email from your system(s) and
inform us. It may contain information that is confidential or
otherwise privileged, and should not be copied or redistributed to
recipients not originally specified as addressees without permission.

S F Blinkhorn MA PhD CPsychol FBPsS, Managing Director,
Psychometric Research & Development Ltd.
PO Box 1143, St Albans, Herts, AL1 9UT, UK
Registered in England No. 1909571
Registered Office: Verulam Point, Station Way, St Albans, Herts, AL1 5HE
Phone: [phone]
http://www.prd.co.uk
****************************************************************************

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg A. Woods]

At Fri, 4 Mar 2022 17:26:23 +0000 (UTC), ***@prd.co.uk (Steve Blinkhorn) wrote:
Subject: Re: groff issue after upgrade to NetBSD-9.2

Post by Steve Blinkhorn
Unpacking the textproc set overwrites files like
/usr/share/groff_font/devps/DESC and devps/download, and maybe other
files which have been adapted or expanded locally. The unpacking
process follows any symbolic link that devps has been set to rather
than overwriting the symbolic link with a hard directory. Fortunately
I have backups. Would this not be worth a warning in the installation
guide - it's a similar issue to /etc, where precious lolcalisations
risk being lost?

Yeah, I would say most of those are not normally files that any end user
would be expected to localise.

I think the best you can hope for is, perhaps, in a future upgrade
if/when syspkgs are used, that there may someday be some conflict
detection for locally modified system files.

That said, you could also add any system files you've customised to
/etc/mtree/special.local and they'll be backed up, with complete daily
automatic version control, into /var/backups by /etc/security. See
"check_changelist" in security.conf(5).

Post by Steve Blinkhorn
I know thered is a move not to includee groff etc. in the main
distribution, but some of us use it extensively: I have substantial
software systems which emit *roff source files, it's not just a
manpage generator.

Perhaps you would be a lot happier with a more modern troff?

I would suggest trying out pkgsrc/textproc/heirloom-doctools

Despite the name, these are quite modernised versions of the original
true AT&T Troff and related tools from what was effectively the
Documenter's Workbench. These tools even have a special "groff"
compatability mode if indeed you depend on any Groff extensions.

See https://n-t-roff.github.io/heirloom/doctools.html

(There is also a port of old DWB-3 (3.3b) in pkgsrc/textproc/DWB, but it
has not been modernised nearly so much.)

One potentially huge advantage of using doctools over the base-system
groff would be that you can much more easily customise (and test!) the
tools and their configuration by applying local patches via pkgsrc.

That said I've long argued for these heirloom-doctools to be used to
replace the base system Groff, and I would still strongly suggest that
be done.

--
Greg A. Woods <***@acm.org>

Kelowna, BC [phone] RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Avoncote Farms <***@avoncote.ca>

[Steve Blinkhorn]

Thanks, helpful and enlightening, and I am pursuing the
Heirloom distribution. Shame about the name, though, sounds like
'legacy' which has come to mean out-of-date. Troff is one of those
software designs that far exceeded in its capabilities the purposes
for which it was originally designed.

But I have to dispute the matter of ordinary users not needing to
modify files. The DESC file as distributed supposes a North American
user base, with the papersize variable set to letter. This has a
number of minor implications for layout specification, but also
results in printers either demanding that letter-size paper be loaded,
which means at the least fiddling with printer settings to pretend
that A4 paper is really letter size paper, or in some cases the
document just not printing in my experience.

And are people generally happy with the standard PostScript fonts? I
find them ugly and old-fashioned for the most part. We dropped
Palatino as our standard house style once PostScript printers came
along - its version of Palatino is much uglier than the one we used
with DEC LN03 laser printers way back.

The fact that the Heirloom release has much more flexible font-file
handling is a real benefit: it was sweated labour converting our font
collection to be usable with groff (but it is a big collection).

--

--pgp-sign-Multipart_Fri_Mar__4_13:00:52_2022-1
Content-Type: text/plain; charset=US-ASCII
Subject: Re: groff issue after upgrade to NetBSD-9.2

Post by Steve Blinkhorn
Unpacking the textproc set overwrites files like
/usr/share/groff_font/devps/DESC and devps/download, and maybe other
files which have been adapted or expanded locally. The unpacking
process follows any symbolic link that devps has been set to rather
than overwriting the symbolic link with a hard directory. Fortunately
I have backups. Would this not be worth a warning in the installation
guide - it's a similar issue to /etc, where precious lolcalisations
risk being lost?

Yeah, I would say most of those are not normally files that any end user
would be expected to localise.
I think the best you can hope for is, perhaps, in a future upgrade
if/when syspkgs are used, that there may someday be some conflict
detection for locally modified system files.
That said, you could also add any system files you've customised to
/etc/mtree/special.local and they'll be backed up, with complete daily
automatic version control, into /var/backups by /etc/security. See
"check_changelist" in security.conf(5).

Post by Steve Blinkhorn
I know thered is a move not to includee groff etc. in the main
distribution, but some of us use it extensively: I have substantial
software systems which emit *roff source files, it's not just a
manpage generator.

Perhaps you would be a lot happier with a more modern troff?
I would suggest trying out pkgsrc/textproc/heirloom-doctools
Despite the name, these are quite modernised versions of the original
true AT&T Troff and related tools from what was effectively the
Documenter's Workbench. These tools even have a special "groff"
compatability mode if indeed you depend on any Groff extensions.
See https://n-t-roff.github.io/heirloom/doctools.html
(There is also a port of old DWB-3 (3.3b) in pkgsrc/textproc/DWB, but it
has not been modernised nearly so much.)
One potentially huge advantage of using doctools over the base-system
groff would be that you can much more easily customise (and test!) the
tools and their configuration by applying local patches via pkgsrc.
That said I've long argued for these heirloom-doctools to be used to
replace the base system Groff, and I would still strongly suggest that
be done.
--
--pgp-sign-Multipart_Fri_Mar__4_13:00:52_2022-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCYiJ+CgAKCRBmfXG3eL/0
f0oRAKDMqBxxElSggKN/9RYKEQvdclC5RQCgoKe1rCm1eWYuravXT4YPc6hprP8=
=TQ7D
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Fri_Mar__4_13:00:52_2022-1--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Steve Blinkhorn
Thanks, helpful and enlightening, and I am pursuing the
Heirloom distribution. Shame about the name, though, sounds like
'legacy' which has come to mean out-of-date. Troff is one of those
software designs that far exceeded in its capabilities the purposes
for which it was originally designed.
But I have to dispute the matter of ordinary users not needing to
modify files. The DESC file as distributed supposes a North American
user base, with the papersize variable set to letter. This has a
number of minor implications for layout specification, but also
results in printers either demanding that letter-size paper be loaded,
which means at the least fiddling with printer settings to pretend
that A4 paper is really letter size paper, or in some cases the
document just not printing in my experience.

I think the general expectation might be users that need to modify
settings take a copy of the relevant groff_font dir and set
GROFF_FONT_PATH

(That doesn't change the fact that NetBSD would benefit from a better
way of managing locally modified files on upgrades :)

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de