groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Werner LEMBERG
Subject: Re: [Groff] redefining symbols on a per-font basis
Date: Thu, 12 Feb 2015 08:14:24 +0100 (CET)

> [...] Between checking .char definitions (which apply to all fonts)
> and checking the current font, there should be a check for a
> font-specific definition that overrides the symbol defined in that
> font.
>
> This omission makes it impossible to straightforwardly redefine
> select symbols in select fonts.  (.fschar is meant as a
> font-specific symbol definition, but it is only a fallback
> mechanism; it cannot hide a symbol in the current font because it is
> not checked until after the current font is checked.)
>
> For instance, one might want to redefine italic parentheses to
> instead output roman parentheses (as advised by Robert Bringhurst in
> his "Elements of Typographic Style").  This would require mapping
> the italic parentheses characters to roman, mapping the bold italic
> ones to bold roman, and leaving the roman and bold ones alone.
> There does not appear to be any straightforward way to do this under
> the current set of requests.
>
> 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.  As a work-around, I suggest that you define a `font
environment' that sets up proper `.char' definitions as soon as you
enter it.  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?

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.

  .de paren
  .  nop \fR(\fP\,\$1\/\fR)\fP
  ..
  foo
  .paren bar
  baz

> (As an aside, the first sentence of the manual excerpt quoted above
> is missing a verb; it should probably read "Here are the exact
> rules...")

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


    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]