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/