[bug #62150] [afmtodit] should not write full file names to "name" directive of font descriptions

[G. Branden Robinson]

Follow-up Comment #2, bug #62150 (project groff):

[comment #1 comment #1:]
> Hey, thanks for opening this bug report!
> 
> A couple nits in the proposed patch:
> 
> > +$short_version =~ s/([0-9.]+)(rc[0-9]+).*/$1$2/;
> 
> That regex (equivalently but more simply written as
> 
>   /([0-9.]+rc[0-9]+).*/$1/
> 
> and more perlishly as
> 
>   /([\d.]+rc\d+).*/$1/
> 
> ) fails to match, and thus leaves $short_version unchanged, if the version
string contains no .rc component, which a development build might not (if I
correctly recall from the very-long-ago days when we weren't in a release
cycle).

Yes, I shared a highly preliminary and un-fully-baked version of the patch. 
:)  I was also dithering over the issue you raised next, of just how much
version info to include.
 
> One could craft a regex to strip the git addendum whether or not the version
string contains an .rc component.  However, absent such a component, you may
_want_ to keep the git-appended portion, as this might then be the only thing
distinguishing an official release from a development build.  (If those dusty
neurons serve correctly, our pre-rc1 build version strings were of the form
1.22.4.git-stuff; turning this into plain 1.22.4 seems misleading.)  Thus,
maybe the limitation I'm noting is intentional.

I have conflicting goals.

1. I wanted to get some of the noise out of the version number for
re-generated PostScript font description files that we can ship in a release.
2. I wanted to make it possible to regenerate these files well _before_ making
the final 1.23.0 tag.  The idea is to to have all the work essentially done
for the release (at whatever point) that happens, and then just make the tags
and send an email.  The less stuff that has to be done to finalize the release
on the day it happens, the easier it will be to increase the release cadence.

> But then, if you're keeping .git-stuff in some cases, why not keep it in all
cases for consistency?  Yeah, it's kinda ugly, but for the most part only
developers will see it, and they should be the people least put off by long
strings of hex digits.  (And might even occasionally appreciate the extra
precision.)

Yeah.  What I had in that diff ended up between two stools.

> > -print("name $font\n");
> > +my $name = $font;
> > +$name =~ s@.*/@@;
> > +
> > +print("name $name\n");
> 
> Nothing wrong with this, but I wonder why it introduces a new variable. 
$font is never again used after this, so may as well hack it directly.

Because I prefer semantic to misleading variable names.  ;-)  Perl is not the
level of programming where we need to emulate a register allocator.  It might
help if I renamed $font to $font_file or similar.

Thanks for the review!  Very soon my grand plan to regenerate those font
descriptions is going to be gated on finding the most recent versions of the
AFM files from Adobe, which I recently learned is discontinuing Type 1 support
altogether, and has done so already in some products.

I see that printafm(1) is of ancient vintage, and probably available anywhere
GhostScript is.  TrueType handling might therefore be easier than I thought.

    _______________________________________________________

Reply to this item at:

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

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