comment #6:

> There's a ticket about this already, wondering about the
> complexity of it.  See bug #56015.

Oh, the ticket where I proposed a patch less than two months ago?  Yes, I'm, uh, dimly aware of it.

> But even if the translation weren't occurring, you'd still
> find that `rchar` didn't work on a font-supplied character.

I wouldn't expect it to, but it seemed immaterial here since neither ascii nor latin1 has a font supplying \[bu].  The purpose of the .rchar in that test was to remove the effect of the .fchar pointed out in comment #3.

> I'm blocked on that pending negotiation with Peter.  ;-)

Apparently my brain has blocked any information relevant to this issue.  I promise to stop posting puzzles to which I already know the solution for the rest of today.

Hmm, I'm hard-pressed to explain this, though.

$ cat bullet_test
.if c\[bu] .tm Bullet exists.
.rchar \[bu]
.if c\[bu] .tm Bullet still exists.
$ groff -Tascii bullet_test
Bullet exists.
$ groff -Tlatin1 bullet_test
Bullet exists.
Bullet still exists.

The bullet (U+2022) is not a Latin-1 character.  It does not appear in tmac/latin1.tmac or any file in font/devlatin1.  The DESC files in font/devascii and font/devlatin1 are identical.

comment #2:

> comment #1:
> > An unfortunate property of the "unicode" directive documented in
> > groff_font(5) is that it causes this test to always succeed.
>
> Be that as it may, the test for \[bu] also succeeds in devascii, despite font/devascii/DESC not specifying the "unicode" directive,
> and no other files in font/devascii having "bu" in their "charset" sections.

Right, because \[bu] is defined for that output device with `fchar`, in tty.tmac.

When you query an ordinary or special character with, say, `.if c`, and you get a "yes" answer, you don't know where the "defined character" comes from.  Might be a fully fledged character definition.  Might be a fallback character.  Might be font-specific fallback character.  Might come from a special font.  Might be a real glyph in the currently mounted font.

If that seems like a uselessly vague "yes" to you, see bug #64004.

Yes.  An unfortunate property of the "unicode" directive documented in groff_font(5) is that it causes this test to always succeed.