[bug #58894] remove nonfunctional lines from groff font files

[Dave]

URL:
<https://savannah.gnu.org/bugs/?58894>

Summary: remove nonfunctional lines from groff font files
Project: GNU troff
Submitted by: barx
Submitted on: Tue 04 Aug 2020 01:11:19 AM CDT
Category: Font devps
Severity: 3 - Normal
Item Group: Warning/Suspicious behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:

As bug #58718 observes, groff does not allow kernpairs in its font files with
a space as the first element.

Despite this, several kernpair entries in a handful of font files
(specifically font/devps/{[HN]*,PR}) have "u0020" as the first element. True
to Werner's assertion, these lines seem to have no effect.


$ cat kerntest
.de sample
A Very Yellow Tortoise Always Wins.
..
.ps 24
.vs 24
.nf
.sp
.fam N
.sample
.fam New
.sample
.fam Newest
.sample
$ mkdir /tmp/devps
$ grep -v ^u0020 /usr/share/groff/current/font/devps/NR > /tmp/devps/NewR
$ grep -v '^[VTY] ' /usr/share/groff/current/font/devps/NR >
/tmp/devps/NewestR
$ groff -F/tmp kerntest > kerntest.ps


The first two lines of the resulting PostScript file look identical, despite
the lines using font files that specify different kerning rules around spaces.
The third output line definitely shows by contrast the absence of kerning
after some of the capital letters.

Groff shouldn't ship font files with lines that don't do the advertised job.
Ideally, bug #58718 would be fixed so that these lines _do_ work. But if a
fix for that bug is not ready by the time of the next release, the
nonfunctional lines in the font files should be removed.




_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58894>

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

[G. Branden Robinson]

Update of bug #58894 (project groff):

Status: None => Need Info

_______________________________________________________

Follow-up Comment #1:

As far as I know, no one actually has any objection to the space-kerning
feature. How about we comment out these lines with a reference to the
Savannah big?

I'm all for deleting dead code or incorrect comments but this would be
neither. Instead it would be a reminder to anyone who sees the comments that
this is an area where they can contribute to groff. :)

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58894>

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

[Dave]

Follow-up Comment #2, bug #58894 (project groff):

Makes sense to me. Communicating via comments that groff ignores these lines
is important to anyone looking at the files who might otherwise conclude this
is a useful thing to do. But the lines don't actually have any effect, so
whether they're specifically commented _out_ (as opposed to merely being
commented upon) doesn't seem to matter much.

As bug #57506 notes, the font files in devps live in a gray area between
original source files and generated files. I don't know how much of their
content comes from afmtodit and how much (if any) is manually edited after the
fact.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58894>

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

[G. Branden Robinson]

Update of bug #58894 (project groff):

Status: Need Info => In Progress


_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58894>

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

[G. Branden Robinson]

Update of bug #58894 (project groff):

Status: In Progress => Need Info

_______________________________________________________

Follow-up Comment #3:

Shifting to "Need Info" because I'm blocked on this until I figure out the
issue(s) raised in bug #57506.

A sort of hack could be done now, my moving existing files to .in and adding
Makefile rules to drive sed scripts to change them, but that is a second-class
solution.

If someone experiments a bit (it might end up being me), or if one of the
steely-eyed old font experts can speak up to show us the way, the correct path
should not prove too difficult.

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58894>

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