[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

Follow-up Comment #14, bug #63018 (group groff):

[comment #9 comment #9:]
> Hi Dave,
> 
> [comment #8 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 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.
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 can see the difference between the two fonts TR (original grops file) and
U-TR produced from latest afm file. Depending on which particular version of
the URW fonts you have installed will affect your results, but on the version
I have installed the original (copied from grops) has under 300 kernpairs
defined but U-TR has about 4200. The actual glyph widths are largely the same,
but the difference in the kerning data may make a difference in output.

I did a little test, using the U-foundry fonts to generate the
groff_man_pages.pdf, and differences are not hard to spot, see the two screen
shots. For this reason I don't think it is a good idea to refresh the original
font files or everyone's documents will change slightly from what used to be
produced. It may annoy a lot of users who have crafted a document to be
"perfect" typographically (in their eyes) but will not appear again with such
perfection. This was the reason I have the U-foundry in devpdf, you can choose
if you want the traditional spacing or latest (which is not guaranteed to stay
the same between versions because they are generated as part of the build),
and having static groff font files makes checking for regressions between
versions slightly easier.

As regards whether to describe my new ZD file as handcrafted or generated, it
is of course, both. For the reasons given above, I consider it important to
retain the traditional spacing in our stock fonts, so all the columns except
the first are from the original afmtodit, as documented in the header, the
name column has been updated with the groff unicode names, which is what would
have happened if the current dingbats.map was used for the original run when
ZD was first created. I'm quite happy to put something in the header like
"unicode names added by Deri 2024", but I certainly would not suggest removing
the afmtodit header which documents the version used, since that is the
program which calculated the font meta-data, not me!

To try to clarify. The ZD file is not a demonstrator, it carefully preserves
the original font meta-data adding the unicode name instead of "---". As to
whether refreshing the file would alter the meta-data, the answer is yes,
about 80 percent of the glyphs have different values for the meta-data.
Admittedly the differences are very small umbers, and may not be noticeable
unless someone is using a program to compare differences in the pdfs produced,
but I would not want to put hand on heart to say there are NO differences
since the values are changed for so many glyphs, which is why I made the
effort to preserve the original meta-data rather than simply regenerate the
font.

(file #56004, file #56005)

    _______________________________________________________

Additional Item Attachment:

File name: grog_TR.png                    Size: 33KiB
    <https://file.savannah.gnu.org/file/grog_TR.png?file_id=56004>

File name: grog_U-TR.png                  Size: 36KiB
    <https://file.savannah.gnu.org/file/grog_U-TR.png?file_id=56005>


    AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-caa52dc0f3fa3d0ef394065c00d653c139eb10e8.tar.gz


    _______________________________________________________

Reply to this item at:

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

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