Re: [Groff] redefining symbols on a per-font basis

[Dave Kemper]

On 2/12/15, Werner LEMBERG <address@hidden> wrote:
>> Am I missing something?  Is there a mechanism to override specific
>> symbols in specific fonts?
>
> You are correct, such a mechanism isn't available.  It has never been
> requested.

I suppose I should go to the bug tracker to remedy that.

> As a work-around, I suggest that you define a `font
> environment' that sets up proper `.char' definitions as soon as you
> enter it.

I don't follow.  The manual seems to indicate that .char definitions
are global, not per-environment.  (Also, arbitrary environments don't
always play well with historical macro packages that assume only the
three traditional troff environments, so this may run into other
issues as a generalized solution.)

> On the other hand, something simple as
>
>   .char ( \fR(\fP
>   .char ) \fR)\fP
>
>   .fam T
>   \fIfoo (\,bar\/) baz\fP
>
>   .fam A
>   \fIfoo (\,bar\/) baz\fP
>
> works just fine.  Isn't this sufficient?

That is sufficient for some cases.  But it incorrectly turns bolding
off when the style is bold or bold italic.

And the more general problem of overriding glyphs on a font-specific
basis goes beyond this parentheses example.  For instance, the Linux
Libertine typeface defines old-style figures, but doesn't give them
names in the font file, requiring them to be accessed via \N.  But the
glyph numbers for these figures are different in each Libertine style,
so a catch-all .char definition won't work.

> In case you want to follow Bringhurst everywhere, I guess you have to
> define a `.paren' macro anyways because `\,' and `\/' have no effect
> within a `.char' definition, IIRC.

True, but I see this as an example of the general limitation
(discussed on this list before) of not being able to define kerning
between characters in different fonts.  Heirloom troff solved this
with the .kernpair request, which would be great to have in groff.
Looks like another trip to the bug tracker!

> I'm quite sure that there are zillions of grammatical
> bugs in the documentation since I'm not a native speaker.

I've noticed very few grammatical errors in the docs.  There are
certain phrasings that are not quite the way a native English speaker
would say something, but rarely ones that obfuscate the meaning.  In
any case, their great organization and thoroughness eclipse any minor
grammatical gaffes.