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

[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/