bugGNU troff - Bugs: bug #57506, Erroneous "slant" value...

 
 

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

Submitted by:  Dave <barx>
Submitted on:  Mon 30 Dec 2019 04:23:19 PM UTC  
 
Category:  Font devps Severity:  2 - Minor
Item Group:  Documentation Status:  Need Info
Privacy:  Public Assigned to:  G. Branden Robinson <gbranden>
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 23 May 2021 07:52:08 AM UTC, comment #5: 

comment #4:

> 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.


No, as of when I wrote that.

Yes, as of commit 0907598d.

Dave <barx>
Project Member
Fri 14 Aug 2020 11:47:23 PM UTC, comment #4: 

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:

> (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.

> 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.

> 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.

Dave <barx>
Project Member
Fri 14 Aug 2020 12:25:28 PM UTC, comment #3: 

> (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.

Deri James <deri>
Project Member
Fri 14 Aug 2020 09:17:23 AM UTC, 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.

G. Branden Robinson <gbranden>
Project AdministratorIn charge of this item.
Tue 17 Mar 2020 08:39:21 AM UTC, comment #1: 

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.

Dave <barx>
Project Member
Mon 30 Dec 2019 04:23:19 PM UTC, original submission:  

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*).

Dave <barx>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-23 barx Severity3 - Normal => 2 - Minor
    2020-08-14 gbranden StatusNone => Need Info
        Assigned toNone => gbranden

    Back to the top


    Powered by Savane 3.7