[bug #57506] Erroneous "slant" value in Times italic font(s) for ps device

[Dave]

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

Summary: Erroneous "slant" value in Times italic font(s) for
ps device
Project: GNU troff
Submitted by: barx
Submitted on: Mon 30 Dec 2019 10:23:19 AM CST
Category: Font devps
Severity: 3 - Normal
Item Group: Documentation
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:

The output of this command, run from the top of the groff source tree (or from
/usr/share/groff/current on a system with groff installed) is highly
questionable:

$ grep ^slant font/devps/T*
font/devps/TBI:slant 15
font/devps/TI:slant 7

It surely isn't correct that Bold Italic has twice the slant of Italic for the
ps device. The slants appear visually identical (as they should), and the
slant values are identical in every other pair of Italic / Bold Italic fonts
in font/devps (grep ^slant font/devps/*), and nearly identical for Times
Italic and Times Bold Italic in every other font/dev* directory (grep ^slant
font/dev*/T*).




_______________________________________________________

Reply to this item at:

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

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

[Dave]

Follow-up Comment #1, bug #57506 (project groff):

This bug dates to at least groff 1.02: commit 351da0dc, the oldest available
in git, shows that both of these files (then in directory ps/devps) had the
same slant values then that they have today.


$ git show 351da0dc:ps/devps/TI | grep ^slant
slant 7
$ git show 351da0dc:ps/devps/TBI | grep ^slant
slant 15


But these files, while they are groff source files (in that they live in the
groff source-code repository), do not appear to be actual source files, in
that they are built by font/devps/generate/Makefile (today, or
ps/devps/FontMakefile back in commit 351da0dc). Thus this bug may be in the
source files that TI and TBI are built from, or in the tools used to build
them.

The primary tool is the afmtodit Perl script, which is part of groff
(src/utils/afmtodit/afmtodit.pl, or ps/devps/afmtodit back in 351da0dc).

I am not sure of the origin of the primary source files, Times-Italic.afm and
Times-BoldItalic.afm. They don't live in the groff source tree (if they did,
presumably TI and TBI would not, instead being built by the groff build
process) or anywhere on my system. The Makefile expects them to be in
/usr/local/lib/afm.

_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Update of bug #57506 (project groff):

Status: None => Need Info
Assigned to: None => gbranden

_______________________________________________________

Follow-up Comment #2:

It seems to me that these files should be regenerated, if not on every build,
then at least for every release.

However, given that the original font files whose metrics are taken are
proprietary Adobe fonts (correct me if I'm wrong), that creates kind of a
sticky wicket from a Debian software-freedom perspective. It's the sort of
thing that knocks a package from "main" into "contrib" (because at build or
runtime it depends on non-free stuff).

The good news is while 20 years ago, popular opinion was that freely-licensed
fonts were an unrealistic concept because font design was too specialized, too
unrewarding, or too hard for anyone to do it under a FLOSS license, that
wisdom has been exposed as the fallacy it always was.

I have a vague understanding that there exist "metrically-equivalent" fonts
for all sorts of popular proprietary fonts. If there are ones for the devps
fonts, then by definition it should be impossible to tell from which fonts the
metrics were extracted.

This also raises the possibility of simply shipping the free fonts with groff
and installing them, though this might be superfluous as they're surely
packaged and managed elsewhere.

I feel like I know a little but not quite enough to move this bug forward.

(1) It's important to determine whether these files are purely generated by
afmtodit or whether they undergo hand-editing afterwards. Either way, this
procedure should become part of the build or release-management process
(depending on the tedium level).

(2) Do free replacements all of the devps fonts exist? Even if not, one can
argue against the "contribification" of groff within Debian by observing that
the metrics extracted from such fonts are not encumbered by copyright; if they
were, the creation of unlicensed replacements as Free Software would not have
been possible in the first place. It's furthermore my understanding, that, at
least in the United States, copyright resides in digital fonts only insofar as
they effectively contain programs to perform hinting. So bitmapped (raster)
and outline fonts are not copyrightable.

(3) If the answer to (2) is no, we should be able to just extract the metrics
from the Adobe fonts in some convenient format, keep that in the source tree,
and then perform transforms on that. Right? It seems like this would break
the function of afmtodit in half--extract metrics from fonts, then rewrite the
metrics in ditroff, possibly with fixups like the one requested in this
ticket. Except maybe this is already done--AFM is after all the format that
afmtodit reads, and in the enscript package on my Debian system I see .afm
files that seem to match most, albeit not all, of the fonts we have in devps.

(4) Do we need to do something similar for the basic 14 PDF fonts?

(5) The end result I envision, if several of my assumptions above are correct,
would look like this:

A. Keep Free, Adobe-compatible PFA fonts, or metric data extracted from
non-Free Adobe PFA fonts in the source tree, in the form of .afm files.
B. Run afmtodit on these.
C. Run ed or sed scripts to apply corrections or improvements.
D. Ship the result as we do today.

In conclusion, the the fixup envisioned here, as well as any others, like
adding space kerning information where the fonts don't provide it themselves,
would become part of step C above.

This font stuff gets me pretty far out of my comfort zone so please correct
all misconceptions I have above.

_______________________________________________________

Reply to this item at:

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

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

[Deri James]

Post by G. Branden Robinson
(4) Do we need to do something similar for the basic 14 PDF fonts?

As part of install these are copied from the font/devps directory.



_______________________________________________________

Reply to this item at:

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

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

[Dave]

Follow-up Comment #4, bug #57506 (project groff):

You raise important questions, to which I don't know any answers. You
demonstrate more font knowledge in comment #2 than I have in my entire brain.

[comment #2 comment #2:]

Post by G. Branden Robinson
(1) It's important to determine whether these files are purely
generated by afmtodit or whether they undergo hand-editing afterwards.

A question also relevant to bug #58894 and bug #58897.

Werner probably knows the answer.

http://lists.gnu.org/archive/html/groff/2020-08/msg00024.html suggests that
John Gardner knows a thing or two about fonts as well.

Post by G. Branden Robinson
Either way, this procedure should become part of the build
or release-management process (depending on the tedium level).

Bug #57594 also concerns an update that should be done every release cycle. I
wondered there (and haven't investigated any further to try to answer myself)
whether there's a checklist of updates to run for each release.

Post by G. Branden Robinson
extract metrics from fonts, then rewrite the metrics in ditroff,
possibly with fixups like the one requested in this ticket.

One would ideally hope the original font files contain correct data, or that
if they don't, bugs can be reported somewhere to get them corrected, so that
we don't have to patch font metrics for every release in perpetuity.

_______________________________________________________

Reply to this item at:

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

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