Not opposed to that either.  I might wonder if the GNU project feels at all territorial about the g prefix, since they use that to distinguish some of their own versions of tools from their ancestors (gmake, gcc, gawk, even gtroff on some systems), but since there's no prior "font" command, I can't see much objection on those grounds.

comment #17:

> comment #16:
> > My suggestion for a name is fforg.
>
> Too many letters in common with fontforge, of which it looks
> like an abbreviation.

This was my first mental association on reading the name.  But I'm not sure whether I consider that disqualifying.  It is related to font conversions, akin to a mini-FontForge for a specific domain.

> Also, the name gives no indication of the script's function
> or domain of operation.

This, however, seems entirely consistent with a Unix command-line name space strewn with inscrutable letter-salads like grep, fsck, ls, cat, gcc, sudo, cd, chmod, awk, and even groff.  And while some groff tools hint at their family relation (grotty, gropdf, grog), plenty more do not (preconv, chem, addftinfo, soelim, afmtodit).

comment #7:

> Branden mentioned two more to-do items in the email cited in comment #5:
> * giving it a less name-space-stomperific name ("groff-font-install" or "groff-install-font" would be clear enough, but I think either would annoy me [and other users] when tab-completing "groff")

My suggestion for a name is fforg.

You might pronounce this as "F-for-G", or the same as "fork", but with a voiced final stop consonant.

1.  It's short for "*f*onts for *g*roff".
2.  It's "groff" spelled backwards.
3.  Anyone frustrated with the tool can call for us to be burned/hanged/shot in...efforgy.

comment #6:

> a first cut that simply checks whether bash is available and
> bails gracefully if not.

With no objection in the past two weeks, I'm calling that a ringing endorsement of this plan!

> Four years ago, James K. Lowden volunteered to do this
> (http://lists.gnu.org/r/groff/2020-04/msg00071.html).  I'm adding
> him to the cc to see if he's still up for this.

James, with the man page text already written (see the last paragraph in comment #11), are you willing do this markup?  This is a considerably simpler task than writing a man page from scratch, but perhaps a less appealing one to you.  I can take this on, but I've never used man markup, whereas someone familiar with it could knock this out quickly.

comment #11:

> There's no copyright affixed to the script, but I can add one and
> slap on a GPL notice if that would help.  Let me know.  There'll
> probably have to be a copyright assignment to the Free Software
> Foundation as well.  I don't keep up with the legalities, I'm afraid.

Nor I; someone more conversant with licensing will have to address this.  I only brought it up as part of a list of potential obstacles I could see to getting it into the package.  I don't know what if anything needs to be done here.  My naïve assumption would be that whatever was done to get -mom in would be sufficient.

> FWIW, a manpage is already written as a heredoc in the script.
> All it needs is to be marked up.

More good news!

Great!  I guess now it's a matter of seeing if anyone has objections to the plan.

The upside that I see is that once the current install-font is under groff's git, changes to make it more POSIX-compliant can be made incrementally, rather than having to do that all at once as a prerequisite for even getting it into git.  (As far as I know, doing this work shouldn't make it any less bash-compatible, but perhaps traps lie there that I'm unaware of.)

The potential downside depends on whether Peter wants to continue to maintain his script separately, which would make the groff git version a fork that will then not automatically pick up any changes Peter makes to his copy.  But he may be willing to make the git code the authoritative version, and simply mirror that on his site (until, presumably, it's part of an official groff release).

I also don't know what license covers the script (neither the page that hosts the script (linked in comment #0), nor the source code itself, mentions one), but my presumption is that it would be licensed the same as -mom herself, which is GPLed.

Peter, would you care to address the above two points?

comment #6:

> > * Write some test cases to ensure it works as expected
>
> It's possible Peter Schaffter, the script's developer, has some he's used privately and would be willing to share.  Putting him on cc as well.

Sorry, no test cases, just the 500+ fonts I've installed successfully with the script.

original submission:

> * Make the script portable by removing dependencies on
> bash-specific features

I'm now wondering if there's some wisdom to doing a first cut that simply checks whether bash is available and bails gracefully if not.  This would leave some users out in the cold, but it would serve a lot of them, and that's got to be an improvement over serving none.  And it wouldn't require a bash install dependency for groff, just a run-time one for one groff utility that provides functionality groff didn't provide before anyway.

> * Write a man page

Four years ago, James K. Lowden volunteered to do this (http://lists.gnu.org/r/groff/2020-04/msg00071.html).  I'm adding him to the cc to see if he's still up for this.  Divide and conquer!

> * Write some test cases to ensure it works as expected

It's possible Peter Schaffter, the script's developer, has some he's used privately and would be willing to share.  Putting him on cc as well.

Sorry, things have been busy.  I intend to devote more time to this soon.

T. Kurt Bond has graciously volunteered to tackle this!  http://lists.gnu.org/archive/html/groff/2021-07/msg00105.html

Savannah won't let me assign this ticket to him -- he probably needs to be a member of the project first -- but I am setting it to "In Progress."

Script location: https://www.schaffter.ca/mom/mom-05.html#install-font

Use of the install-font.sh script makes installing fonts for groff much, much easier.  It should be integrated into groff.

Preliminary Tasks

• Make the script portable by removing dependencies on bash-specific features - see http://lists.gnu.org/archive/html/groff/2020-04/msg00079.html

and downthread; thread continues, not linked to the previous one, at
http://lists.gnu.org/archive/html/groff/2020-05/msg00000.html

• Write a man page
• Write some test cases to ensure it works as expected

Mailing List Discussion

• Initial suggestion with tasks involved: https://lists.gnu.org/archive/html/groff/2021-07/msg00061.html
• Further discussion of tasks and links to previous discussion: https://lists.gnu.org/archive/html/groff/2021-07/msg00065.html
• Difficulties in making the script general enough to handle the inconsistences of distributions due to different locations or absence of the site-font directory: https://lists.gnu.org/archive/html/groff/2021-07/msg00063.html
  • https://lists.gnu.org/archive/html/groff/2021-07/msg00071.html