Hi Branden,

Yes, that looks good.

comment #44:

>
> comment #39:
> > Hi Deri,
> >
> > The comment fields for the glyphs in the ZD font description file don't seem to be accurate.  They don't look like correct Unicode correspondences to me.  Or at least most don't.
> >
> Hi Dave,

Comment #39 was me, too.  :)
 

> No, it does not look correct, I suspect you did not use the dingbats.map file attached to this bug.

Okay, that explains the pattern I've seen.
 

> In comment #43 Branden reports he is now seeing the BALLOT X glyph, so either he is using the ZD font I provided, or he ran afmtodit with the new dingbats.map.

Yes.

Here are the commits I have queued up in my working copy, in forward commit order.

commit 366bbf358b11d9c2d4f7b1780f5aa8f6cf7c2db1
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:52:58 2024 -0500

    Revert "tmac/fallbacks.tmac: Define fallback for U+2717."

    This reverts commit 12c0f8a0b8df51085ce862d232ffc020ac7a5d26.

    `fchar` is not the right remedy for the scenario I had in mind.  Oddly,
    `schar` might not be, either.

commit 179e896e1f8f0de675d5943f6b0ed105efb0f654
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:02:25 2024 -0500

    src/utils/afmtodit/afmtodit.pl: Refactor (1/4).

    * src/utils/afmtodit/afmtodit.pl: Define `prog` scalar as only the
      "basename" of argv[0], making diagnostic and usage messages less
      garrulous; see Savannah #65110.

commit 44b9700a0e892059ac4d6c6284468e845801cecf
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:06:13 2024 -0500

    src/utils/afmtodit/afmtodit.pl: Refactor (2/4).

    * src/utils/afmtodit/afmtodit.pl: Add new `opt_w` scalar to separate it
      from existing `space_width` scalar so that we can report the options
      we were invoked with in a comment in the generated file.

commit 1141fe44a8dd95813745e6445baf59203d0bdd1a
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:11:29 2024 -0500

    src/utils/afmtodit/afmtodit.pl: Refactor (3/4).

    * src/utils/afmtodit/afmtodit.pl: Reorganize scalar representation of
      version information: new `groff_version`, which is populated at build
      time, new `short_version` which is `groff_version` stripped of any Git
      revision and partial hash information; new `version_stub` which holds
      the prefixed information identifying the program and project; new
      `output_version` which holds the stub and the short version; and
      existing `afmtodit_version`, which holds the stub and the (full) groff
      version.  Write `output_version` instead of `afmtodit_version` to the
      generated file.

commit 647856053a46e0e29b1ca8d0bb62a0021250b6a1
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:15:26 2024 -0500

    src/utils/afmtodit/afmtodit.pl: Refactor (4/4).

    * src/utils/afmtodit/afmtodit.pl: Update call sites of `croak` and new
      `whine` subroutines to use `&` sigil and omit trailing newline.

      (croak): Assume responsibility for writing a newline at the end of the
      message.

      (whine): New subroutine throws a diagnostic marked "warning".  Perl's
      `warn` output is ugly and not structured like other groff diagnostics.
      Give it responsibility for emitting the name of the program.

commit 65d5d2e6d4af0f58ad369788ac653aa2b9c492cf
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:20:53 2024 -0500

    [afmtodit]: Improve generated comments.

    * src/utils/afmtodit/afmtodit.pl: Improve information written to
      generated font description files in comments.  Name the AFM and map
      files used.  Report any options specified on the command line.  The
      idea is to make it easier for future (and current) maintainers to
      update such files because years pass between occurrences, and
      institutional memory is, if not lost, laborious to dredge up.  This
      practice might also assist users in producing groff description files
      for their own fonts.  Also write out a glyph's corresponding Unicode
      code point in the comment field only if one is defined.  Otherwise we
      get a comment marker followed by a tab and a newline, which Git marks
      in radioactive red.

commit c4e48771fb53ba8f393bf63f3de7a6a7225642ad
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 07:25:44 2024 -0500

    font/devps/ZD: Regenerate using updated afmtodit.

    No changes to font description data relative to Werner's commit
    7a7ef828ef, 19 May 2010.

    This reverts Deri's commit 98b0c1db4, 12 April, but only temporarily in
    effect.  The reason is to prove the foregoing equivalence.

    See <https://savannah.gnu.org/bugs/?63018>.

commit e831086c82d7b17a0ec16efe99836e30f8473747
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Mon Apr 29 17:00:15 2024 +0000

    font/devps/generate/dingbats.map: Update.

    ...to map many more Unicode code points to Zapf Dingbats glyphs.

commit d5be30ad67f3d1d41e9cd2976919f2bb4666d642
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:30:41 2024 -0500

    font/devps/generate/dingbats.map: Drop 2 mappings.

    afmtodit complains.

    afmtodit: warning: you are not allowed to map the PostScript character 'space'
    afmtodit: warning: you are not allowed to map the PostScript character 'space'

    (It'd be nice if afmtodit identified the file name and line number it
    was complaining about...)

commit ca20c8375d3cc393041db141ab7deddd94d926ca (HEAD -> master)
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Aug 21 08:40:27 2024 -0500

    font/devps/ZD: Regen from updated dingbats.map.

    * font/devps/ZD: Regenerate using updated dingbats.map.

    Fixes <https://savannah.gnu.org/bugs/?63018>.  Thanks to Deri James and
    Dave Kemper for (extensive) consultation.

Does this look okay to you?

commit 12c0f8a0b8df51085ce862d232ffc020ac7a5d26
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue Aug 20 10:17:25 2024 -0500

    tmac/fallbacks.tmac: Define fallback for U+2717.

    * tmac/fallbacks.tmac: Define fallback character for U+2717 "BALLOT X".

This was a blunder; I'll have to revert it.

Oddly, changing this `fchar` to `schar` doesn't solve the problem and is documented not to:

     .schar c contents
                Define global fallback character c as contents.  As
                char, but a character defined with schar is located
                after the list of fonts declared with the .special
                request and before any mounted special fonts.

"before any mounted special fonts"

But what if we want an even-farther-fallback for when even mounted special fonts come up dry?  I have some homework to understand why this was thought unnecessary.  Or how to do it.

Anyway, reverting that commit and rebuilding "groff-man-pages.pdf" makes Deri's new tables in gropdf(1) and groff_tmac(5) nice and pretty.  The "BALLOT X" glyph gets snarfed from the ZD font given only the special character input `\[u2717]`.

So I'm pretty much set to go, I think, but will wait for Deri's feedback.

comment #39:

> Here are the changes to "afmtodit.pl".

Of the three calls to new subroutine whine(), two are invoked with the & prefix and one without.  Is this intentional?

Hi Deri,

The comment fields for the glyphs in the ZD font description file don't seem to be accurate.  They don't look like correct Unicode correspondences to me.  Or at least most don't.

charset
space   278     0       32      space
---     974,621 3       33      a1      --      0021
---     961,611 3       34      a2      --      0022
---     974,621 3       35      a202    --      0023
---     980,692 3       36      a3      --      0024
---     719,566 3       37      a4      --      0025
---     789,705,14      3       38      a5      --      0026
---     790,705,14      3       39      a119    --      2019
---     791,705,13      3       40      a118    --      0028
---     690,553 3       41      a117    --      0029
---     960,568 3       42      a11     --      002A
rh      939,559 3       43      a12     --      002B
---     549,705,11      3       44      a13     --      002C
...

Those code points 0021..002C can't be right, can they?

I've got some patches for afmtodit ready.  Using my patched version I can recreate the contents of the ZD file as of Werner's last change to it.

commit 7a7ef828efa6292b44d5530f0efb3ea993aac125
Author: Werner LEMBERG <wl@gnu.org>
Date:   Wed May 19 06:22:37 2010 +0000

    Update symbol tables for devps font generation.

    * font/devps/generate/textmap: Sort alphabetically.
    Replace tabs with spaces.

    * font/devps/generate/symbolchars: Update list to remove duplicates
    which have already been added to `textmap' on 2007-04-09.

    * font/devps/symbolmap: Regenerated.

    * font/devps/*: Regenerate font definition files.

...except for the comment header, which I changed on purpose.

Here's the command and the diff.

$ ./build/afmtodit -cms -i 0 /tmp/Adobe-Core35_AFMs-314/ZapfDingbats.afm font/devps/generate/dingbats.map ./font/devps/ZD
$ git diff 7a7ef828efa6292b44d5530f0efb3ea993aac125 font/devps/ZDdiff --git a/font/devps/ZD b/font/devps/ZD
index 2ffaf6b00..6acfbc750 100644
--- a/font/devps/ZD
+++ b/font/devps/ZD
@@ -1,10 +1,13 @@
-# This file has been generated with GNU afmtodit (groff) version 1.20.1
+# generated by GNU afmtodit (groff) version 1.23.0
+#   AFM file: /tmp/Adobe-Core35_AFMs-314/ZapfDingbats.afm
+#   map file: font/devps/generate/dingbats.map
+#   with options "-c -i 0 -m -s"
 #
 #   FullName ITC Zapf Dingbats
 #   Version 002.000
 #   FamilyName ITC Zapf Dingbats
 #
-# The original AFM file contains the following comments:
+# The AFM file contained the following comments.
 #
 #   Notice Copyright (c) 1985, 1987, 1988, 1989, 1997 Adobe Systems Incorporated. All Rights Reserved.ITC Zapf Dingbats is a registered trademark of International Typeface Corporation.
 #   Comment Copyright (c) 1985, 1987, 1988, 1989, 1997 Adobe Systems Incorporated. All Rights Reserved.

Here are the changes to "afmtodit.pl".

commit 5e7fccb0e653e189cea119a2d843e5d2cd5e49bc (HEAD)
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue Aug 20 21:48:10 2024 -0500

    XXX src/utils/afmtodit/afmtodit.pl

diff --git a/src/utils/afmtodit/afmtodit.pl b/src/utils/afmtodit/afmtodit.pl
index d85defd6f..84588cb38 100644
--- a/src/utils/afmtodit/afmtodit.pl
+++ b/src/utils/afmtodit/afmtodit.pl
@@ -1,5 +1,5 @@
 #!@PERL@
-# Copyright (C) 1989-2020 Free Software Foundation, Inc.
+# Copyright (C) 1989-2024 Free Software Foundation, Inc.
 #      Written by James Clark (jjc@jclark.com)
 #
 # This file is part of groff.
@@ -22,21 +22,34 @@ use strict;

 @afmtodit.tables@

-my $prog = $0;
+use File::Spec qw(splitpath);
+(undef,undef,my $prog)=File::Spec->splitpath($0);
+
 my $groff_sys_fontdir = "@FONTDIR@";
 my $want_help;
 my $space_width = 0;

 our ($opt_a, $opt_c, $opt_d, $opt_e, $opt_f, $opt_i, $opt_k,
-     $opt_m, $opt_n, $opt_o, $opt_s, $opt_v, $opt_x);
+     $opt_m, $opt_n, $opt_o, $opt_s, $opt_v, $opt_w, $opt_x);

 use Getopt::Long qw(:config gnu_getopt);
 GetOptions( "a=s", "c", "d=s", "e=s", "f=s", "i=s", "k", "m", "n",
-  "o=s", "s", "v", "w=i" => \$space_width, "x", "version" => \$opt_v,
+  "o=s", "s", "v", "w=i", "x", "version" => \$opt_v,
   "help" => \$want_help
 );

-my $afmtodit_version = "GNU afmtodit (groff) version @VERSION@";
+# We keep these two scalars separate so we can report out the option.
+$space_width = $opt_w if $opt_w;
+
+# Preserve the Git revision and partial hash from development builds in
+# `--version` output, but scrub it from comments written to files.
+my $groff_version = "@VERSION@";
+my $short_version = $groff_version;
+$short_version =~ s/(\d+\.\d+.\d+).*/$1/;
+
+my $version_stub = "GNU afmtodit (groff) version";
+my $afmtodit_version = "$version_stub $groff_version";
+my $output_version = "$version_stub $short_version";

 if ($opt_v) {
     print "$afmtodit_version\n";
@@ -45,10 +58,15 @@ if ($opt_v) {

 sub croak {
   my $msg = shift;
-  print STDERR "$prog: error: $msg";
+  print STDERR "$prog: error: $msg\n";
   exit(1);
 }

+sub whine {
+  my $msg = shift;
+  print STDERR "$prog: warning: $msg\n";
+}
+
 sub usage {
     my $stream = *STDOUT;
     my $had_error = shift;
@@ -100,7 +118,7 @@ my (@encoding, %in_encoding);
 my (%width, %height, %depth);
 my (%left_side_bearing, %right_side_bearing);

-open(AFM, $afm) || croak("unable to open '$ARGV[0]': $!\n");
+open(AFM, $afm) || &croak("unable to open '$ARGV[0]': $!\n");

 while (<AFM>) {
     chomp;
@@ -214,7 +232,7 @@ my ($sizescale, $resolution, $unitwidth);
 $sizescale = 1;

 open(DESC, $desc) || open(DESC, $sys_desc) ||
-    croak("unable to open '$desc' or '$sys_desc': $!\n");
+    &croak("unable to open '$desc' or '$sys_desc': $!\n");
 while (<DESC>) {
     next if /^#/;
     chop;
@@ -238,7 +256,7 @@ if ($opt_e) {

     my $sys_opt_e = $groff_sys_fontdir . "/devps/" . $opt_e;
     open(ENCODING, $opt_e) || open(ENCODING, $sys_opt_e) ||
-       croak("unable to open '$opt_e' or '$sys_opt_e': $!\n");
+       &croak("unable to open '$opt_e' or '$sys_opt_e': $!\n");
     while (<ENCODING>) {
        next if /^#/;
        chop;
@@ -259,7 +277,7 @@ if ($opt_e) {
 my (%nmap, %map);

 open(MAP, $map) || open(MAP, $sys_map) ||
-    croak("unable to open '$map' or '$sys_map': $!\n");
+    &croak("unable to open '$map' or '$sys_map': $!\n");
 while (<MAP>) {
     next if /^#/;
     chop;
@@ -269,12 +287,12 @@ while (<MAP>) {
        if ($field[1] eq "space") {
            # The PostScript character "space" is automatically mapped
            # to the groff character "space"; this is for grops.
-           warn "$prog: you are not allowed to map to " .
-                "the groff character 'space'";
+           &whine("$prog: you are not allowed to map to " .
+                  "the groff character 'space'");
        }
        elsif ($field[0] eq "space") {
-           warn "$prog: you are not allowed to map " .
-                "the PostScript character 'space'";
+           &whine("$prog: you are not allowed to map " .
+                  "the PostScript character 'space'");
        }
        else {
            $nmap{$field[0]} += 0;
@@ -421,7 +439,7 @@ if (!$opt_x) {
            $u =~ s/^_/u/;
            if ($u) {
                if (defined $mapped{$u}) {
-                   warn "$prog: both $mapped{$u} and $ch map to $u";
+                   whine("$prog: both $mapped{$u} and $ch map to $u");
                }
                else {
                    $mapped{$u} = $ch;
@@ -453,10 +471,31 @@ foreach my $lig (sort keys %default_ligatures) {
 # print it all out

 open(FONT, ">$outfile") ||
-  croak("unable to open '$outfile' for writing: $!\n");
+  &croak("unable to open '$outfile' for writing: $!\n");
 select(FONT);

-print("# This file was generated with $afmtodit_version.\n");
+my @options;
+
+push @options, "-a $opt_a" if defined $opt_a;
+push @options, "-c"        if defined $opt_c;
+push @options, "-d $opt_d" if defined $opt_d;
+push @options, "-e $opt_e" if defined $opt_e;
+push @options, "-f $opt_f" if defined $opt_f;
+push @options, "-i $opt_i" if defined $opt_i;
+push @options, "-k"        if defined $opt_k;
+push @options, "-m"        if defined $opt_m;
+push @options, "-n"        if defined $opt_n;
+push @options, "-o $opt_o" if defined $opt_o;
+push @options, "-s"        if defined $opt_s;
+push @options, "-v"        if defined $opt_v;
+push @options, "-w $opt_w" if defined $opt_w;
+
+my $opts = join ' ', @options;
+
+print("# generated by $output_version\n");
+print("#   AFM file: $afm\n");
+print("#   map file: $map\n");
+print("#   with options \"$opts\"\n") if @options;
 print("#\n");
 print("#   $fullname\n") if defined $fullname;
 print("#   $version\n") if defined $version;
@@ -465,7 +504,7 @@ print("#   $familyname\n") if defined $familyname;
 if ($opt_c) {
     print("#\n");
     if (defined $notice || @comments) {
-       print("# The original AFM file contains the following comments:\n");
+       print("# The AFM file contained the following comments.\n");
        print("#\n");
        print("#   $notice\n") if defined $notice;
        foreach my $comment (@comments) {
@@ -473,7 +512,7 @@ if ($opt_c) {
        }
     }
     else {
-       print("# The original AFM file contains no comments.\n");
+       print("# The AFM file contained no comments.\n");
     }
 }

@@ -621,7 +660,9 @@ for (my $i = 0; $i <= $#encoding; $i++) {
            printf(",%d", conv($h));
        }
        printf("\t%d", $type);
-       printf("\t%d\t%s\t%s\t%s\n", $i, $ch, '--', $AGL_to_unicode{$ch}||'');
+       my $comment = '';
+       $comment .= "\t-- " . $AGL_to_unicode{$ch} if ($AGL_to_unicode{$ch});
+       printf("\t%d\t%s%s\n", $i, $ch, $comment);
        if (defined $nmap{$ch}) {
            for (my $j = 1; $j < $nmap{$ch}; $j++) {
                printf("%s\t\"\n", $map{$ch, $j});

Does this look okay to you?  If so, I'll break it up into sensible change sets and then regenerate ZD (and I guess ZDR) and commit them.  Then add your new "dingbats.map" file, and regenerate and commit again.  (It's important to me to prove reconstructibility of the font descriptions grops has used for 12 years.)  That should resolve this ticket, I think.

But I'll also take a look at the "BALLOT X" symbols in groff_tmac(5) to verify that they're not using a fallback.

I apologize for the clumsiness of my Perl.

comment #36:

> > Branden, do I need to open a separate ticket for this?
>
> Yes, for different maintainer-mode targets

Everybody, welcome bug #66033 to the world.

Self-follow-up:

comment #34:

> > The main wandering was the desire to make the grops fonts to
> > be generated during a groff build,
>
> But this should definitely be a separate ticket:

It might even be bug #65698 (which was spawned from Branden's list of tasks in comment #13).  Or maybe #65698 is merely a prerequisite for generating the grops fonts?  I don't have much of a handle on what #65698 is asking for.  (I did open it, but merely parroting Branden's words.)

Branden, do I need to open a separate ticket for this?

Hi Dave,

This started off as a simple request to give access to Dingbats glyphs via their \[uXXXX] names... and then wandered!

The main wandering was the desire to make the grops fonts to be generated during a groff build, and I have given up on that little beauty, although it is 99% doable. So we are stuck with grops fonts in aspic, we just deliver the file as part of groff.

This means the solution to this bug is simple: install the new dingbats.map file and run the current afmtodit (with appropriate parameters), using the current dingbats.afm file, and replace the current ZD and ZDR files with the results.

There is no manual editing of the font files required.

I have been investigating the AFMs Branden found with a view to using them as a way to recreate the grops fonts, particularly in situations where there have been changes to the maps, encoding files and afmtodit itself. Since the last release afmtodit, and dingbats map have been altered, and the grops fonts have been hand edited by me to add the UTF-16 code as a comment. Afmtodit is to be changed soon to add the new spacewidth algorithm and improvements to the font comments.

For all these reasons it would be convenient to have an automated procedure which generates the grops fonts. The attached grops-fonts-AFMs.tar.gz has everything required to do this. It contains the afms from the Adobe-Core35_AFMs-229.tar.gz from CTAN, with one change, the Symbol.afm has been replaced with symbol.afm from the git grops directory, since I suspect this has been edited to work best with eqn. Investigation showed that the original Symbol.afm from the 229 tar.gz produced different italic corrections, whereas the copy from the grops directory produces identical results.

All the AFMs have had the ellipsis kerning lines added, (see script EllipsisFix.sh - a blatant rip off from Daves code in bug #58897 - except it now operates on the KPX lines in the AFM files, so no need to run it again, but left in place to show what was done).

The script BuildPSfonts.pl runs afmtodit with the correct parameters. It takes 4 parameters:-

BuildPSfonts.pl [-F font-directory] [-map directory-with-map-files] [-enc directory-with-enc-files] [-afm directory-with-afm-files]

From the build directory I ran it with this parameter:-

./BuildPSfonts.pl -F ./devps -enc ../font/devps -map ../font/devps/generate -afm grops-fonts-AFMs

Note I used a separate directory for the new fonts so I could then compare them with the current files for checking.

When you check the results you will notice a few differences:-

The final glyph in each file has a different UTF-16 comment, the new versions are correct, mistake in my hand editing when I committed them, the new generated files are correct.

In some fonts there is one case where the position of the ellipsis and period kern lines are swapped, this has no effect, it happens when afmtodit is processing a glyph alias (i.e. when two groff names refer to the same glyph, contains just a name and a " in the font entry. In this case generates two kern entries and sorts them alphabetically. Dave's sed script which added an epsilon kern after each '.' kern, so the order would be like this:-

. rq -70
u2026 rq -70
. ' -70
u2026 ' -70

Whereas afmtodit sorts the kern list alphabetically so it becomes:-

. rq -70
. ' -70
u2026 rq -70
u2026 ' -70

This has no effect.

The S font has the most changes. There is a new glyph Upsilon which is not in the current font, and it is given the groff name "u03A5" rather than *U,which is assigned to 03D2 "GREEK UPSILON WITH HOOK SYMBOL", so I don't think this will cause an issue. The rest of the difference are all to do with the comment field and have no effect.

The SS font is a problem. There is a file called symbolsl.afm in the devps directory which one could reasonably assume was used to produce the SS file via afmtodit. However, if you look at the file you will see it has problems:-

C 33 ; WX 333 ; N exclam ; B 128 -13 240 686 ;

The width is shown as 333, but this produces:-

---     296,598,15,137,-73,99   3       33      exclam

Where the width is now 296 (=333*.89) and the height goes from 673 (686-13) to 598 (=673*.89). The .89 factor is from the transformation applied to the normal symbol file in the file symbolsl.ps:-

%%IncludeResource: font Symbol

/Symbol-Slanted
[.89 0.0 15.5 dup sin exch cos div .89 0.0 0.0]
/Symbol
MakeTransformedFont

Which seems to be a zoom factor plus either a rotate or shear transformation (my maths is not up to it). I was 17 before I had my first proper maths lesson, the benefits of going to a school where you are not expected to be academic. :-)

So I don't think we can faithfully reproduce the SS font from source files, unless someone is mathematical enough to apply a transformation to the llx, lly, urx, ury (which defines a rectangle) so if someone can convert the postscript transformation to a formula which converts the rectangle, we could add it as an option to afmtodit

Another issue which applies to SS, is that because it is defined in DESC fonts before the S font and will be searched first, it is important that only the symbol glyphs we want to become slanted (i.e. lowercase greek for equations) are named, the rest need to be unnamed (---) so groff will look for them in the normal symbol font instead. This script does that as well.

I have done a fair bit of work on this, because I think it is important we have the ability to recreate the grops fonts, but I am now stuck: need help with the maths outlined above and also guidance on implementing this as a make target.

(file #56053)

Dave.

I think the implied question is: When it is a separate make target (bug #65698), if we wish to retain the epsilon kerns the make target must either re-apply the shell script after the font generation, or these "gold" AFMs should have the extra kerns added once before we pour aspic on them. The make targe then gets run whenever afmtodit, the maps, or the encoding files, are altered.

As far as I can tell the "slant" parameter does nothing for composite (e.g. a glyph plus an accent glyph on top of each other) placement. What it does do is affect both italic correction factors and the subscript correction, i.e. when a font switches from roman to italic for example.

Branden.

You piqued my curiosity about Hungarian umlauts, so I took a peak at the list archives. :-)

There are two issues with Gergő's predicament. His package was built with no URW fonts whatsoever, even though the required fonts are sitting in /usr/share/fonts/Type1/ as can be seen in the list of files supplied to Alex. I know this because the pdf he supplied had absolutely no embedded fonts in it, so if you cast your mind back to the games played with the URW font detection during configure, he has the setup where only the base 14 pdf fonts would be available (without warnings about missing fonts). The placement of the umlauts is because the standard fonts lack the four individual glyphs, so groff sends a composite:-

wx font 5 TR
f5
h13750
Ca"
to
wh13750
Ca"
tO
wh13750
Ca"
tu
wh13750
Ca"
tU

Where the U- foundry fonts have separate glyphs:-

wx font 42 U-TR
f42
h13750
Cu006F_030B
wh41250
Cu004F_030B
wh53460
Cu0075_030B
wh41250
Cu0055_030B

In the attached pdf you can see that in the U- fonts the height of the umlaut is fitted to the height of the letter, since the glyph is custom designed. It is always better to use a single glyph rather than composing a compose. I did send him some information how to access those URW fonts by just replacing the TR, TI... With 4 custom versions, but it was just an email, since I am no longer on the list, so it may get filed as "junk".

Also, because of the big pointsize, it is easier to see what is happening. In TI and TBI you can see the umlaut is slightly shifted to the right, this has nothing to do with "slant" it is just an artifact of the probable transformation applied to TR to arrive at TI when the font was designed.

(file #56036)

comment #26:

> I have been investigating the AFMs contained in the tar files Branden referenced in comment #15.

Oh, cool, you tracked 'em down.  I couldn't remember if I had renamed them for my own benefit or if I found them on the Web with those names.

> Using the 229 versions it is possible to generate the 35 fonts for grops. The only difference is that our fonts include kerning data for the ellipsis font which is not included in the AFMs, because commit 81b4ffadc1ced modified the files via a shell script to duplicate the full stop kerning information to ellipsis.

And Dave just happens to be right here, ready for the spotlight. ;-)
 

> I have only tested the TR and TI fonts and I used the following afmtodit commands:-
>
> ./afmtodit -c -i0 -m -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Roman.afm font/devpdf/map/text.map DJTR
>
> ./afmtodit -c -i50 -a7 -e ../font/devps/text.enc Adobe-Core35_AFMs-229/Times-Italic.afm font/devpdf/map/text.map DJTI
>
> For italic fonts you need to ensure that the "slant" value (-a) matches the value used previously, (in case of Times-Italic the AFM has an Italic Angle of 15.5, but the groff font was clearly produced with a slant of 7, i.e. it was overridden with the -a flag). I don't know why this was done, it is the only one with such an override:-

[snip]

> Maybe some people on the list may know.

I'm afraid I don't have any insight into that decision.

More broadly, I wonder if this slant value selection is related to the gripe this month on the development list about Hungarian umlauts.

> It is a good thing Branden found the AFMs since the conversion from afm to a groff font is not completely reversible.

Maybe it is time we extended afmtodit with whatever features we need to make possible a fully automatic transformation from the Adobe AFMs, which are certainly fully fossilized by now, to groff font description files.

To that end, I am reassigning the ticket to you, Deri, but setting status to "None" so as to not prejudge the next step you take.

You can of course reassign it again if you like.

comment #24:

> That's not, in my opinion, strictly coupled to the problem of determining the space width.  Certainly not a bad thing to do, but it should be a separate commit.  Oh, and even more so since as Dave points out below, it's a separate bug report too.

Please assign bug #65697 to yourself (or ask Dave or me to) if you want to claim it; it will help prevent a collision with other contributors.

Don't read too much into my opening multiple tickets: they're not saying "THESE THINGS MUST BE DONE" but giving venues to consider and discuss separate issues without cluttering this bug.  At least that was the theory. ;-}  Any ticket can be closed without action taken if that ultimately seems the right approach.

comment #22:

> If vintage afm files are not forthcoming, then (2 - makefile
> target) is moot.

Perhaps, or perhaps it's worth implementing anyway so as to be ready if the files ever materialize.  Either way, that discussion has little to do with this ticket's focus (the ZD characters).

> But this already has its own bug #65659 which is assigned to
> me and I'm doing font research.

(This presumably means bug #65619, as 65659 is for another project.)

Bug #65619 seems to cover different ground than bug #65697.  Neither one seems dependent on the other to me, though if I'm wrong, savannah now allows showing bug dependencies.

True for the third ticket of that trio, but the first two can be implemented regardless of the fate of the old AFM files.

As for the third, it documents a different issue from this ticket and should have its own venue, so that when this ticket is closed, side conversations about development goals aren't forgotten.  If a fix proves not doable -- whether because the original AFM files are lost in the mists of time, or for any other reason -- that ticket can document the reason(s).

comment #13:

> In fact I see two issues springing thence.  So, to summarize.
>
> 1.  Make comment headers of font description files we generate
> with tools more informative.

Now bug #65697.

> 2.  Add "maintainer-font-descriptions" make(1) targets for
> afmtodit and maybe hpdftodit and tfmtodit.

Now bug #65698.

> 3.  Update the procedure documented in "FOR-RELEASE" to include
> the effects of item 2 above.

Now bug #65699, depending on the previous one.

It is a bit moot now. If Branden does have the original afms for the grops fonts, which produce identical meta-data as currently, then much better to run afmtodit on all of them as a refresh.

comment #14:

> There is a slight wrinkle with this. Although we have the groff font files for devps, we don't have the original pfa and afm files which were used to generate those files. If we use the current generation of URW fonts, as the U-foundry in devpdf does, you will see differences between what is produced now, with current .afm files and afmtodit, and what was produced when the original grops fonts were created.

You've refreshed my memory.  There might not be a problem here.  I happen to have the following files lying around.  According to their time stamps, I grabbed them over 2 years ago.

Adobe-Core35_AFMs-229.tar.gz
Adobe-Core35_AFMs-314.tar.gz

If I'm not mistaken, these generate the font description files in font/devps and font/devps/old.

The proof of the pudding is of course in the afmtoditting.

I'll report back when I know more.

comment #12:

> comment #11:
> > It might help if we said so in the comment.  We could
> > furthermore include in that comment the presence/values of
> > command-line options that affect the generated contents.
>
> If you're talking about modifying afmtodit to include that information in its output, that seems like a good idea but well outside this ticket's scope.

Sure, just noting it so I don't forget.  It can become a separate ticket, as can comment #7.  In fact I see two issues springing thence.  So, to summarize.

1.  Make comment headers of font description files we generate with tools more informative.  Could affect afmtodit, hpftodit, tfmtodit, addftinfo, and xtotroff.

2.  Add "maintainer-font-descriptions" make(1) targets for afmtodit and maybe hpdftodit and tfmtodit.  (This might depend on what source material we already have in the tree.  If such material is missing (or so stale we should toss it out), we might need to document further maintainer-mode build dependencies in "INSTALL.REPO".)

3.  Update the procedure documented in "FOR-RELEASE" to include the effects of item 2 above.

comment #10:

> comment #9:
> > I understood Deri as proposing to update "dingbats.map" and
> > regenerating the ZD file using afmtodit with it...
>
> Ah.  I did not grasp that the latter was generated from the former.

It might help if we said so in the comment.  We could furthermore include in that comment the presence/values of command-line options that affect the generated contents.

Hi Dave,

comment #8:

> To clarify: my objection isn't the stale afmtodit version

It is nevertheless a legitimate one.  We should be dogfooding the font description files that afmtodit generates.

We also should not be advertising a file as automatically generated when it was hand-crafted.

> (I doubt refreshing the file will change the data),

If you mean re-running it as of groff 1.23.0 or recent Git, I agree: probably not.

> but that the line claims afmtodit generated it at all: once Deri's ZD is committed, precious little of its content will be from afmtodit.

I understood Deri as proposing to update "dingbats.map" and regenerating the ZD file using afmtodit with it...

comment #5:

> Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate).  Also attached is a replacement ZD file to be placed in fonts/devps.

...hence the characterization of the "ZD" file as supplementary; I assume it was a demonstrator and/or a convenience for people who didn't want to fiddle with coming up with an afmtodit command invocation themselves.

> Doing make will propagate the changes to devpdf and when U-ZD is created it will use the new dingbats.map.

This matches my understanding.

comment #6:

> The introductory comment line should probably also be amended, since it currently says "This file has been generated with GNU afmtodit (groff) version 1.20.1" and that's no longer true for 99% of the file's content.

Our "FOR-RELEASE" file says this:

* Update font description files that we generate from external data and
  provide with our source distribution.

    Directory  Format                  Tool
    ---------  ------                  ----
    devX*      X11 core/server font    xtotroff

  The make(1) target "maintainer-font-descriptions" produces these font
  descriptions.

I remember having plans to add the grops (and consequently gropdf) font description files to this step...but I don't remember finishing everything I thought I needed to do for it.

Maybe this can be an opportunity to complete that procedure, and apply it.

Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate). Also attached is a replacement ZD file to be placed in fonts/devps. Doing make will propagate the changes to devpdf and when U-ZD is created it will use the new dingbats.map.

The attached .trf file includes all the characters in the unicode 2700 code page (see U2700.pdf). When you run it you will see that some code points are missing from the font, this probably because the font was created before unicode and there have been numerous changes.

ZDR is a different kettle of fish! It does not make sense reversing many of the glyphs, and they would not have unicodes anyway. We currently only have one entry in reversed-dingbats.map, for \[lh]. For gropdf we have it defined in pdf.tmac as:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'


(file #55989, file #55990, file #55991, file #55992)

original submission:

> defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so
> that they can also be represented respectively by \[u2713] \[u261E]

On further thought, because these aliases should apply to both the ps and pdf devices, they shouldn't be in a file that only the ps device reads.

Luckily, the font description file itself includes a mechanism to define aliases for the same glyph.  From the info manual:

   A line in the 'charset' section can also have the form

     NAME "

identifying NAME as another name for the glyph mentioned in the preceding line.

(On first blush, it may seem that defining this alias in font/devps/ZD still only applies to the ps device.  However, font/devpdf is populated from font/devps, so aliases in the devps font description file propagate to the devpdf one.)

Adding the author of the patched ZD to this ticket's cc: list in case he has further thoughts on its integration into groff.