comment #44:

> I suspect you're not using echo(1) the way you think you are.

I admit I didn't consider its portability, but on my system it output what I intended.

> Because the default style is 'R', and the font 'ZDR' exists (on
> the  "ps" default output device), this actually works.

Yes, I misinterpreted my results earlier.  In fact groff does fail on a bogus family.

$ groff -fBOGUS
troff: fatal error: invalid default font family 'BOGUS'

So there's nothing more to be done here.  Sorry for the red herring.

comment #41:

>     Now:
>    
>     $ echo | ./build/test-groff -fZD -a
>     <beginning of page>

A vast improvement!

But maybe a little too quiet: groff disregards the -fZD flag without telling the user it's doing so.

echo "\N'110'" | groff -ww -fZD

This fails to load the ZD family (because there is no such thing) or the ZD font (because that's not what -f does), so outputs an "n" rather than a solid square.  The invalid -f ought to at least provoke a warning, at least when all warnings are activate.

This could reasonably be considered a separate bug, so I'm happy to open a new report if warranted.

I'll follow up with a brief (I hope) recapitulation of my lost comment.

The following bug-closing context will help reduce the length of that.

commit 609d962fc02e517744ee4f68160648a78df3a020
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat May 11 09:54:35 2024 -0500

    [tmac]: Perform actual string comparisons.

    * tmac/fallbacks.tmac:
    * tmac/troffrc-end: Bracket comparands to formatted output comparison
      operator with `\?` escape sequences to perform a more elementary
      string comparison on them (cf. a comparison of _formatted text_).
      This way they continue to perform their function even if the default
      font family has no coverage of Basic Latin (not a bizarre choice when
      considering potential rendering of documents using Devanagari or East
      Asian languages).  Unfortunately this means of comparing strings,
      while long documented in the GNU troff Manual, is neither idiomatic
      for *roff macro programmers nor portable to AT&T troff.  (The *roff
      language historically _lacks_ a string comparison operator.)  Each
      macro package will have to decide for itself whether it wants to have
      portability at the expense of requiring Basic Latin coverage (possibly
      switching fonts before and after a formatted output comparison for the
      sole purpose of obtaining it).  These two files are unconditionally
      loaded by the stock `troffrc`, and therefore must be dealt with in any
      case.

    Fixes <https://savannah.gnu.org/bugs/?64155>.  Thanks to Dave Kemper for
    the report, and to him, Peter Schaffter, and Deri James for the
    discussion.

    Previously:

    $ echo | groff -fZD -a
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'p' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 's' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'a' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'c' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:14: warning: character 'i' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'l' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 't' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:16: warning: character 'n' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'u' not defined
    troff:/.../groff/1.23.0/tmac/fallbacks.tmac:17: warning: character 'f' not defined
    troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'h' not defined
    troff:/.../groff/1.23.0/tmac/troffrc-end:7: warning: character 'm' not defined
    <beginning of page>

    Now:

    $ echo | ./build/test-groff -fZD -a
    <beginning of page>

Self-followup:

comment #37:

> in a way back compatible to almost any older troff.

Obviously, this specific example is not AT&T-portable due to the long names, but the logic can be written portably.

comment #34:

> Maybe it is time for a proper string equality operator in our
> conditional expressions.

While that would be a useful addition to the language, equivalent functionality can be achieved in user space, in a way back compatible to almost any older troff.

.de string_compare
.  ft TR
.  ie '\\$1'\\$2' .nr strings_equal 1
.  el .nr strings_equal 0
.  ft P
..
.
.ft ZD
.
.if 'foo'foo' .tm foo = foo, via output comparison operator
.if 'foo'bar' .tm foo = bar, via output comparison operator
.
.string_compare foo foo
.if \n[strings_equal] .tm foo = foo, via string_compare macro
.string_compare foo bar
.if \n[strings_equal] .tm foo = bar, via string_compare macro

comment #34:

> > > Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid
> >
> > I think I can answer this - it is certainly not invalid, it just has nothing to do with ZD not being a "proper" family (in your eyes).
>
> This isn't a matter of my subjective opinion; the "family" and "style" features of groff date back to 1990.
>
> https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.115?h=1.23.0#n5535
>
> There is a long AT&T troff hangover of assuming that `R`, `I`, and `B` fonts will exist (or, in groff, that abstract styles that work analogously to fonts of those names will).  This assumption can extend to `S` as well.

I don't dispute R, I, B, and BI is a family, it's not the only possible family, previously a font family of just R and B would be happily accepted and \fBword\fP worked as expected. It was your code which insisted on a far more inflexible rule.

[...]

> > If you do -fZD, which has no alphabetic glyphs, any start up macros which contain conditional statements of the form:-
> >
> > .if '\*[.T]'html' \" etc..
> >
> > Will produce character not found errors, since, as we know, both sides are formatted in separate environments and compared.
>
> Yes.  I find this troublesome.
>
> It seems to be an idiom to use the output comparison operator (a term I had to coin, for it had no name) for string comparisons even when there is no intention of formatting either of the comparands as text.
>
> But that idiom would seem to port poorly to document environments where the basic Latin alphabet doesn't need to be formatted at all.
>
> > The give away in Dave's initial report is that the "character undefined" errors spell out the words "ps/pdf/html" at least can be seen.
>
> You paid better attention than I did.  I managed to overlook it, staring more closely at the 1.23.0 output, seeing only the character sequence "psaciltnufhm", and deducing nothing much in particular from that.
>
> Good sleuthing!
>
> But also there's no way in hell we should be spewing diagnostics on, or failing to correctly perform comparisons within, control structures that are initializing the state of the formatter.  These macro files are profoundly uninterested in formatting any output, and they'd be buggy if they did so, since an empty input document should produce no output no matter what (stock) macro packages or startup macro files you load.
>
> Maybe it is time for a proper string equality operator in our conditional expressions.

Ooh, yes please.

> > I'm sure this "feature" has come up before. Even with Branden's code which stopped -fZD from working did not address the real problem because if you have four fonts with R, I, B, and BI extension but don't contain alphabetic characters, -f works for the "family" but you will see exactly the same errors as Dave reported.
>
> Fair point.
> 
> > One way for a proper fix, is to create a copy of TR as TRSKEL, add the "special" parameter, and change the name parameter to TRSKEL, remove all kernpairs, delete all glyph definitions above 127, and finally alter the DESC file by incrementing the number and adding TRSKEL on the end. This will solve the error occurring if you use -f on fonts which don't contain ascii glyphs, such as some CJK fonts. This can all be done in the devpdf directory (I have done it for testing), but a very similar change can be made to devps as well.
>
> Here, I must disagree.  The foregoing strikes me as a workaround rather than a proper fix.

I agree, it's a workaround, but it is also a proper fix in the sense that it prevented Dave's errors appearing for non-latin fonts, which you agreed your code did not (so was not a proper fix).

[...]

> A string equality test.  Not a comparison of node lists, which are laden with all sorts of other data.[1]  Just a string equality test.
>
> Well, let's give the people what they are asking for.  Especially since a lot of the time, "the people" is us.

+1 here, that would be a proper fix too. What semantics are you considering for this new conditional?

> [1] Now that I've started resurrecting and expanding the formatter's facilities for node dumping, I'm getting a better notion of what all that extra data is.  I begin to revise upward my expectations of the performance improvement I can expect from a straight-up simple string equality operator, particularly since the operation can be handed off to the C++ standard library and from there, likely to platform-specific, optimized assembly code.  It hasn't escaped me that this might also help, say, string comparisons of PDF bookmark tags, since they too are not output to be formatted.

I liked .pline.

comment #32:

> comment #28:
> > comment #27:
> > Specifically, am I correct to claim either of the following?
> >
> > A.  "[G]iven that mom has her own system of managing fonts, and part of her contract with the user [...] is that [the] user will not go behind her back and start invoking *roff requests." is a false statement.  (Possibly an exaggeration.)
>
> Oversimplification, possibly my fault.  You got the idea from this bit of the documentation:
>
> "In some cases, mom’s typesetting macros merely imitate groff primitives. In others, they approach typesetting concerns in conceptually new ways (for groff, at least). This should present no problem for newcomers to groff who are learning mom. Old groff hands should be careful. Just because it looks like a duck and walks like a duck does not, in this instance, mean that it is a duck. When using mom, stay away from groff primitives if mom provides a macro that accomplishes the same thing."

Yes.  I haven't read anything like all of mom's documentation, but the foregoing sounds a fairly large bell in my head.  I likely did overinterpret it.

> That's not a contract, it's a recommendation.  I don't want users imagining. for example, that they can use either .ps or .PT_SIZE interchangeably (or .ft/.FT) and expect the same results.  E.g. if AUTOLEAD is enabled, .PT_SIZE changes the pointsize and updates the leading.  Plain .ps only changes the size, hence the recommendation to stay away from groff primitives if mom provides a macro that accomplishes the same thing.  There a number of macros where the documentation explicitly states that using a primitive instead of a macro is fine.

Acknowledged.
 

> I'm not comfortable with the statement "mom has her own system of managing fonts."  Other than that .FAM and .FT perform checks and set registers needed by other macros, and the inclusion of pre-defined supplementary styles (none loaded in positions 1-4), there is nothing unique about mom's font management.

No indeed; given your clarification above, item A is greatly overstated.

> > B.  The statement "By issuing appropriate formatter instructions, you can override these defaults before your document writes its first glyph." in our manual should be dropped, or revised to stipulate that some macro packages (namely mom), will assume that that before a document requests a glyph to be formatted, mounting position 1 will be assigned to a style named 'R'.
>
> I'm confused.  The docs currently say, "The default mounting position, and therefore style, is always '1' ('R')"  Why would this suddenly only apply to "some" macro packages?  I don't think the B. statement should be dropped, but I would change "these defaults" because the only formatter flag pertinent to that section of the documentation is -f <family>.

I think I can probably leave this item as-is.  I certainly should not add any special caveat about mom, but I think the "these defaults" sentence can stay once the larger context, an introduction to groff's font concept, is considered.

Here is that context.

5.19 Using Fonts
================

In digital typography, a "font" is a collection of characters in a
specific typeface that a device can render as glyphs at a desired
size.(1)  (*note Using Fonts-Footnote-1::) A 'roff' formatter can change
typefaces at any point in the text.  The basic faces are a set of
"styles" combining upright and slanted shapes with normal and heavy
stroke weights: 'R', 'I', 'B', and 'BI'--these stand for roman, italic,
bold, and bold-italic.  For linguistic text, GNU 'troff' groups
typefaces into "families" containing each of these styles.(2)  (*note
Using Fonts-Footnote-2::) A "text font" is thus often a family combined
with a style, but it need not be: consider the 'ps' and 'pdf' devices'
'ZCMI' (Zapf Chancery Medium italic)--often, no other style of Zapf
Chancery Medium is provided.  On typesetters, at least one "special
font" is available, comprising "unstyled" glyphs for mathematical
operators and other purposes.

   Like the AT&T 'troff' formatter, GNU 'troff' does not itself load or
manipulate a digital font file;(3) (*note Using Fonts-Footnote-3::)
instead it works with a "font description file" that characterizes it,
including its glyph repertoire and the "metrics" (dimensions) of each
glyph.(4)  (*note Using Fonts-Footnote-4::) This information permits the
formatter to accurately place glyphs with respect to each other.  Before
using a font description, the formatter associates it with a "mounting
position", a place in an ordered list of available typefaces.  So that a
document need not be strongly coupled to a specific font family, in GNU
'troff' an output device can associate a style in the abstract sense
with a mounting position.  Thus the default family can be combined with
a style dynamically, producing a "resolved font name".  A user-specified
font name that combines family and style (or refers to a font that is
not a member of a family) is already "resolved".

   Fonts often have trademarked names, and even Free Software fonts can
require renaming upon modification.  'groff' maintains a convention that
a device's serif font family is given the name 'T' ("Times"), its
sans-serif family 'H' ("Helvetica"), and its monospaced family 'C'
("Courier").  Historical inertia has driven 'groff''s font identifiers
to short uppercase abbreviations of font names, as with 'TR', 'TI',
'TB', 'TBI', and a special font 'S'.

   The default family used with abstract styles is initially 'T'.
Typically, abstract styles are arranged in the first four mounting
positions in the order shown above.  The default mounting position, and
therefore style, is always '1' ('R').  By issuing appropriate formatter
instructions, you can override these defaults before your document
writes its first glyph.

   Terminals cannot change font families and lack special fonts.  They
support style changes by overstriking, or by altering ISO 6429/ECMA-48
"graphic renditions" (character cell attributes).

I've set the status back to "Confirmed" because my way forward--for the time being--seems clear.

I think Dave's point in comment #31 is worthwhile and demands further consideration.  I don't relish the labor or I/O expense of making a `fam` request hit the file system repeatedly, speculatively loading every registered style for the family being switched to, but maybe that is what is warranted.

comment #27:

> it would be good to know if/how Dave's original report in
> comment #0 was invalid.

I'm fine with -fZD failing on the grounds that groff doesn't consider ZD a family, but the failure mechanism should be cleaner.

> Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid

I think I can answer this - it is certainly not invalid, it just has nothing to do with ZD not being a "proper" family (in your eyes). If you do -fZD, which has no alphabetic glyphs, any start up macros which contain conditional statements of the form:-

.if '\*[.T]'html' \" etc..

Will produce character not found errors, since, as we know, both sides are formatted in separate environments and compared.

The give away in Dave's initial report is that the "character undefined" errors spell out the words "ps/pdf/html" at least can be seen. I'm sure this "feature" has come up before. Even with Branden's code which stopped -fZD from working did not address the real problem because if you have four fonts with R, I, B, and BI extension but don't contain alphabetic characters, -f works for the "family" but you will see exactly the same errors as Dave reported.

One way for a proper fix, is to create a copy of TR as TRSKEL, add the "special" parameter, and change the name parameter to TRSKEL, remove all kernpairs, delete all glyph definitions above 127, and finally alter the DESC file by incrementing the number and adding TRSKEL on the end. This will solve the error occurring if you use -f on fonts which don't contain ascii glyphs, such as some CJK fonts. This can all be done in the devpdf directory (I have done it for testing), but a very similar change can be made to devps as well.

An alternative fix would be to consider including the GNU UnifontMedium font in groff and using it as a special instead of TRSKEL, this has the advantage of solving any undefined glyphs as well, but there are other issues.

Hi Peter,

comment #26:

> I guess I wasn't clear enough when I advised not implementing .fam checking as proposed by Branden,

Please be reassured that this wasn't a matter of proceeding over your protest (5 March 2024); the commit had already been in place on the master branch since 10 July 2023.
 

> as I have just discovered the change has been committed, with the expected consequence: partial families in my library that have only R and I fonts choke on .fam.
>
>   printf ".fam Technical\n.ft R" | groff -z
>   troff:<standard input>:1: error: 'Technical' is not a valid font family
>
> This is a regression.

This example invalidates one of the premises I put forward in comment #22 ("given that mom has her own system of managing fonts, and part of her contract with the user, as I understand it, is that [the] user will not go behind her back and start invoking *roff requests") and regarding which I solicited your input.

It may also invalidate some language I put into our Texinfo manual.

   The default family used with abstract styles is initially 'T'.
Typically, abstract styles are arranged in the first four mounting
positions in the order shown above.  The default mounting position, and
therefore style, is always '1' ('R').  By issuing appropriate formatter
instructions, you can override these defaults before your document
writes its first glyph.

...namely, the final sentence.

Please confirm my understanding of the foregoing and I will proceed with the reversion right away.

> Please revert the commit that introduced it,
> 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.  I don't see any need for .fam checking in the first place, but that discussion should be left for after the commit is reverted.

Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid.

Thanks, Peter.  In light of comment #24, taking this out of Need Info status and reassigning to Branden.

comment #21:

> this code:-

...

> Copied the corrupt file rather than the correct file in
> ./font/devpdf. What is the purpose of this?

This issue being unrelated to this ticket's original purpose (which was fixed and closed with comment #17), I opened bug #65415 to address it separately.

> I am going to leave this open so that you can reply to

...

> whether you think this change will affect mom's use of .fam.

This seems to be the only other question keeping this ticket open now.  Ping: Peter.  (Also assigning the bug to him for now, since Deri has withdrawn from gropdf work.)

Hi Branden,

I've worked it out. This is the problem, I had a corrupt copy of U-TR in my build directory so this code:-

  if test -f $f; then \
    /usr/bin/install -c -m 644 $f /usr/share/groff/1.23.0/font/devpdf/$f; \
  else \
    /usr/bin/install -c -m 644 ./font/devpdf/$f \
      /usr/share/groff/1.23.0/font/devpdf/$f; \
  fi; \

Copied the corrupt file rather than the correct file in ./font/devpdf. What is the purpose of this?

I am going to leave this open so that you can reply to the above and whether you think this change will affect mom's use of .fam.

Also, I am a bit surprised that you must be reading U-TR (rather than just checking for its existence) and then when it fails (silently) it compains about the family, which is confusing, rather than reporting a font as corrupt.

Further testing shows that test-groff works but after a make install it fails!!

test-groff

[pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TR", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26596, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TI", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=30662, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TB", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26563, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TBI", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=30421, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3664, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3664, ...}, AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TR", O_RDONLY) = 3

[derij@pip build (master)]$ ll ~/groff-git/groff/build/font/devpdf/U-T*
-rw-r--r-- 1 derij derij 26563 Feb  5 23:40 /home/derij/groff-git/groff/build/font/devpdf/U-TB
-rw-r--r-- 1 derij derij 30421 Feb  5 23:40 /home/derij/groff-git/groff/build/font/devpdf/U-TBI
-rw-r--r-- 1 derij derij 30662 Feb  5 23:40 /home/derij/groff-git/groff/build/font/devpdf/U-TI
-rw-r--r-- 1 derij derij 26596 Feb  5 23:40 /home/derij/groff-git/groff/build/font/devpdf/U-TR

after install (groff)

[pid 3048720] openat(AT_FDCWD, "/usr/share/groff/1.23.0/font/devpdf/U-TR", O_RDONLY) = 3
[pid 3048720] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=17000, ...}, AT_EMPTY_PATH) = 0
troff: fatal error: 'U-T' is not a valid font family
[pid 3048720] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3048720, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---

[derij@pip build (master)]$ ll /usr/share/groff/1.23.0/font/devpdf/U-T*
-rw-r--r-- 1 root root 26563 Feb  5 23:44 /usr/share/groff/1.23.0/font/devpdf/U-TB
-rw-r--r-- 1 root root 30421 Feb  5 23:44 /usr/share/groff/1.23.0/font/devpdf/U-TBI
-rw-r--r-- 1 root root 30662 Feb  5 23:44 /usr/share/groff/1.23.0/font/devpdf/U-TI
-rw-r--r-- 1 root root 17000 Feb  5 23:44 /usr/share/groff/1.23.0/font/devpdf/U-TR

commit 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu May 25 05:35:25 2023 -0500

    [troff]: Validate a font family before using it.

    * src/roff/troff/env.cpp (is_family_valid): New function checks for all
      text styles (R, I, B, BI) and returns true only if the given family
      supports them all.

      (family_change): Call `is_family_valid()` on given argument.  If
      invalid, throw diagnostic and ignore `fam` request.

    * src/roff/troff/env.h (is_family_valid): Declare; make visible.

    * src/roff/troff/input.cpp (main): Call `is_family_valid()` on `-f`
      option argument.  Its invalidity is a fatal error.

    Fixes <https://savannah.gnu.org/bugs/?64155>.  Thanks to Dave Kemper for
    the report.

    Tested with:

    $ echo | ./build/test-groff -fZD -z
    troff: fatal error: 'ZD' is not a valid font family
    $ echo | ./build/test-groff -fH -z
    $ nl ./EXPERIMENTS/validate-family.groff
         1  .tm .fam=\n[.fam]
         2  .fam H
         3  .tm .fam=\n[.fam]
         4  .fam
         5  .tm .fam=\n[.fam]
         6  .fam ZD
         7  .fam BOGUS
         8  .tm .fam=\n[.fam]
         9  .fam
        10  .tm .fam=\n[.fam]
    $ ./build/test-groff ./EXPERIMENTS/validate-family.groff
    .fam=T
    .fam=H
    .fam=T
    troff:./EXPERIMENTS/validate-family.groff:6: error: 'ZD' is not a valid font family
    troff:./EXPERIMENTS/validate-family.groff:7: error: 'BOGUS' is not a valid font family
    .fam=T
    .fam=H

In my working copy of my private branch.  The commit ID will almost certainly change.

commit f8e966af2985f267ed1efd9c6eeb37e41adca959
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu May 25 05:35:25 2023 -0500

    [troff]: Validate a font family before using it.

    * src/roff/troff/env.cpp (is_family_valid): New function checks for all
      text styles (R, I, B, BI) and returns true only if the given family
      supports them all.

      (family_change): Call `is_family_valid()` on given argument.  If
      invalid, throw diagnostic and ignore `fam` request.

    * src/roff/troff/env.h (is_family_valid): Declare; make visible.

    * src/roff/troff/input.cpp (main): Call `is_family_valid()` on `-f`
      option argument.  Its invalidity is a fatal error.

    Fixes <https://savannah.gnu.org/bugs/?64115>.  Thanks to Dave
    Kemper for the report.

    Tested with:

    $ echo | ./build/test-groff -fZD -z
    troff: fatal error: 'ZD' is not a valid font family
    $ echo | ./build/test-groff -fH -z
    $ nl ./EXPERIMENTS/validate-family.groff
         1  .tm .fam=\n[.fam]
         2  .fam H
         3  .tm .fam=\n[.fam]
         4  .fam
         5  .tm .fam=\n[.fam]
         6  .fam ZD
         7  .fam BOGUS
         8  .tm .fam=\n[.fam]
         9  .fam
        10  .tm .fam=\n[.fam]
    $ ./build/test-groff ./EXPERIMENTS/validate-family.groff
    .fam=T
    .fam=H
    .fam=T
    troff:./EXPERIMENTS/validate-family.groff:6: error: 'ZD' is not a valid font family
    troff:./EXPERIMENTS/validate-family.groff:7: error: 'BOGUS' is not a valid font family
    .fam=T
    .fam=H

I did have to lose the bit of diagnostic about which style was missing, because the function needed to be callable from two different places and passing back that information promised to be a pain in the butt.  It would have meant adding a reference or pointer argument to `is_family_valid`, or introducing C++ exceptions to groff's exception-free code base.  Or something similarly grody, I expect.  It didn't seem worth the trouble at this time.

comment #12:

> comment #11:
> > +       * src/roff/troff/env.cpp (is_family_valid): New function checks
> > +       for all text styles (R, I, B, BI) and returns true only if the
> > +       given family supports them all.
> > +       (family_change): Call `is_family_valid()` on given argument.
> > +       If invalid, throw diagnostic and ignore `fam` request.
>
> If comment #9 is correct, wouldn't this disallow a CJK family?  Or do those fonts not use the family concept?

They don't, yet.  If they're going to, we need to make the "styles" concept considerably more flexible, and probably have it driven by new directives in the device and/or font description files.  I've had a couple of different ideas along these lines, and I don't like either one.

So I reckon we can cross that bridge later.

Here's what I've pushed to my working copy.

diff --git a/ChangeLog b/ChangeLog
index 79163d005..b91609090 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2023-05-25  G. Branden Robinson <g.branden.robinson@gmail.com>
+
+       [troff]: Validate a font family before trying to use it.
+
+       * src/roff/troff/env.cpp (is_family_valid): New function checks
+       for all text styles (R, I, B, BI) and returns true only if the
+       given family supports them all.
+       (family_change): Call `is_family_valid()` on given argument.
+       If invalid, throw diagnostic and ignore `fam` request.
+       * src/roff/troff/env.h (is_family_valid): Declare; make visible.
+       * src/roff/troff/input.cpp (main): Call `is_family_valid()` on
+       `-f` option argument.  Its invalidity is a fatal error.
+
+       Fixes <https://savannah.gnu.org/bugs/?64115>.  Thanks to Dave
+       Kemper for the report.
+
 2023-05-25  G. Branden Robinson <g.branden.robinson@gmail.com>

        * src/roff/troff/env.h (read_hyphen_file): Drop relic prototype
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 4c64273ef..fc14cb715 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -1256,9 +1256,32 @@ void font_change()
   skip_line();
 }

+bool is_family_valid(const char *fam)
+{
+  // std::vector<const char *> styles{"R", "I", "B", "BI"}; // C++11
+  std::vector<const char *> styles;
+  styles.reserve(4);
+  styles.push_back("R");
+  styles.push_back("I");
+  styles.push_back("B");
+  styles.push_back("BI");
+  std::vector<const char *>::iterator style;
+  // for (auto style : styles) // C++11
+  for (style = styles.begin(); style != styles.end(); style++)
+    if (!check_font(fam, *style))
+      return false;
+  return true;
+}
+
 void family_change()
 {
   symbol s = get_name();
+  if (s != 0 /* nullptr */)
+    if (!is_family_valid(s.contents())) {
+      error("'%1' is not a valid font family", s.contents());
+      skip_line();
+      return;
+    }
   curenv->set_family(s);
   skip_line();
 }
diff --git a/src/roff/troff/env.h b/src/roff/troff/env.h
index d98941914..8382d11ea 100644
--- a/src/roff/troff/env.h
+++ b/src/roff/troff/env.h
@@ -408,6 +408,7 @@ extern void pop_env();
 extern void push_env(int);

 void init_environments();
+bool is_family_valid(const char *);

 extern double spread_limit;

diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index cbb8b1ca3..56c20f3eb 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -8333,6 +8333,9 @@ int main(int argc, char **argv)
        warning(WARN_FONT, "cannot mount font '%1' directed by 'DESC'"
                " file for device '%2'", font::font_name_table[i],
                device);
+  if (fflag && !(is_family_valid(default_family.contents())))
+      fatal("'%1' is not a valid font family",
+           default_family.contents());
   curdiv = topdiv = new top_level_diversion;
   if (nflag)
     topdiv->set_next_page_number(next_page_number);

I don't think CJK fonts have I or BI variants (but they can have R and B). To view Japanese man pages something like this is used:-

groff -Tpdf -man -dHF=MB -kt -mja -fM -dpaper=a4 -P-pa4 groff.7  > groff.7.pdf

So it probably would be better to check if the R font of given -f fam contains latin-1 charset (don't need to check all - if 'a' and 'A' are in their latin-1 positions it would be sufficiently indicative).

NB gropdf support for multi thousand glyph fonts is in development, grops already supports.

  My "solution" has a side effect,
so it can't be integrated into the software.

  If an input file is used with some characters,
then it turns out,
that the font "ZDR" is used.

  Thus "ZD" is accepted as a family name,
as the letter "R" is interpreted as meaning a roman font.

comment #3:

> Possibly a search for the requisite styles could be undertaken
> upon use of the `-f` flag or `fam` request, errors thrown for
> any that are missing, and the option or request ignored.

Hmm, that raises a couple of interesting questions.

Is it an error to specify a family where some font styles are missing if the document never asks to use those styles?

Is it an error to specify a family where all font styles are missing if the document never actually uses that family? (e.g., specifying "-fZD" on the command line to process a document whose first line is ".fam T")

This is kind of a case of "don't do that, then".  ("Doctor, it hurts when I do this!")

    -f fam
        Set default font family.

However, Zapf Dingbats is a specific face, not a family.  And not a member of a family.

No matter what happens, you'll get diagnostics, but we probably could improve the diagnostics you get.

Remember this old chestnut?

    troff: EXPERIMENTS/font-errors.groff:23: warning: can't find font 'BOGUSR'

This is pretty close to the actual problem.  If "ZD" is the family, then the formatter expects to find fonts named "ZDR", "ZDI", "ZDB", and "ZDBI".

Possibly a search for the requisite styles could be undertaken upon use of the `-f` flag or `fam` request, errors thrown for any that are missing, and the option or request ignored.

The numeric overflow is interesting.

I suspect this is related to bug #64144 (errors when setting -f to a font which does not contain a full latin-1 character set). It occurs when using .if ''' in a macro so a construct such as .if '\*[.T]'html' will fail when troff generates the output of both to compare.

Branden devised an ingenious solution in bug #64144, it is a bit odd because -T pdf produces a different error:-

[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tps -fEURO -a
troff: fatal error: invalid default font family 'EURO'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tpdf -fEURO -a
troff: fatal error: invalid default font family 'EURO'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tpdf -fZD -a
troff: fatal error: invalid default font family 'ZD'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tps -fZD -a
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning: character 'p' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning: character 's' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning: character 'a' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning: character 'c' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning: character 'i' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning: character 'l' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning: character 't' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning: character 'n' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:17: warning: character 'u' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:17: warning: character 'f' not defined
troff:/home/derij/groff-git/groff/build/../tmac/troffrc-end:7: warning: character 'h' not defined
troff:/home/derij/groff-git/groff/build/../tmac/troffrc-end:7: warning: character 'm' not defined
<beginning of page>

troff:/home/derij/groff-git/groff/build/../tmac/html-end.tmac:20: error: numeric overflow