[Top][All Lists]

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

Re: Groff-1.22.1: No pdfdocdir created

From: Werner LEMBERG
Subject: Re: Groff-1.22.1: No pdfdocdir created
Date: Fri, 04 Jan 2013 11:13:12 +0100 (CET)

[Gunnar, please comment since it affects heirloom troff also.]


thanks for your patches!  I've applied them, except the change to
europs.tmac: You are fixing a very subtle problem in troff which
probably deserves a better solution.

Consider this minimum input file `f'

  .char \[] \f[EURO]x

and process it with

  troff -R f

(option `-R' suppresses the use of start-up files).  On the console
you'll see this:

  f:1: empty escape name
  x T ps
  x res 72000 1 1
  x init
  f:2: warning: can't find character `t'
  f:2: warning: can't find character `e'
  f:2: warning: can't find character `s'
  n12000 0
  x trailer
  x stop

I'm intentionally using `.char' and not `.fschar' in the above example
to demonstrate that this problem in troff is very old, probably from
the very beginning.

Normally, the implementation of `.char' stores its argument within an
internal macro.  However, `\[]' is not a valid character name, thus
`.char' complains.  For almost all routines in troff's source code
which implement the various troff requests, the function `skip_line'
is called in case of error to skip everything up to the (logical) end
of line.  Here's the source code:

  void skip_line()
    while (!tok.newline())
      if (tok.eof())

`tok.next', an instance of `token::next', is a central function in
troff, converting essentially all input data into tokens (which are
stored in `tok' itself).  Consequently, it also handles `\f[EURO]' --
and it indeed sets the current font to `EURO'!  However, since the
characters `t', `e', and `s' are not found in this font, no

  x font 6 EURO

line is emitted in troff's intermediate output; you only see three
error messages instead.

Another example for the problematic behaviour is

  .ds \[] \fBx

Again, `\[]' is not a valid string register name, leading to an error
and the use of `skip_line', which sets the current font to `B' so that
`test' gets printed in bold face.

The question is how to fix this optimally.  Deri's quick solution is
simply to save and restore the current font before and after the
problematic spot, respectively.  It should be rather straightforward
to do it `better', this is, to make `token::next' ignore `\f' and
friends in case of error...

What about other troff implementations?  I've just tried heirloom
troff (compiled from CVS in April 2009), and it exposes exactly the
same incorrect behaviour as GNU troff if I use the above example with


reply via email to

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