Re: Groff-1.22.1: No pdfdocdir created

[Ingo Schwarze]

Hi Werner,

Werner LEMBERG wrote on Sun, Jan 06, 2013 at 12:33:25PM +0100:
> Ingo Schwarze wrote:

>> The mandoc(1) utility does not currently implement .char or .fschar.

> ... it affects a simple `.ds' also, as shown with an example...

Oh, good point, i overlooked that in your posting, sorry.

The mandoc(1) utility does support the roff(7) .ds request.

Given the test file appended at the end of this posting,
i get the following output:

$ /usr/local/bin/nroff -c -mandoc -Tascii char.in > char.out_ascii
char.in:10: name expected (got a special character)
char.in:13: empty escape name

$ mandoc -Tlint char.in 
char.in:10:5: ERROR: escaped character not allowed in a name
char.in:13:5: ERROR: escaped character not allowed in a name

The "test text" is formatted in bold by groff,
but in normal roman font by mandoc.

Thus, mandoc(1) completely ignores a .ds request
if the name contains an escape sequence,
which is the behaviour that you considered as desirable
for groff as well.
It does not insert the definition into the token stream.

[...]
> Certainly.  The question is how seriously we have to take the problem,
> given that we have never received a report related to this issue.
> Normally, a user will notice the problem quite easily since the very
> first error message directly says what the problem is (namely an
> invalid name or font).

Well, even if people rarely run into the problem, if there is an
easy way to improve groff's behaviour, it should probably be done.

> However, in conditional, automated runs it's
> not that easy, as the posted log demonstrates.

Yours,
  Ingo


$ cat char.in
.Dd January 6, 2013
.Dt DS-CHAR 1
.Os OpenBSD
.Sh NAME
.Nm ds-char
.Nd character handling by the define string request
.Sh DESCRIPTION
This is a broken bar: \(bb
.Pp
.ds \(bb \fBx
test text \fR after define string with \e(bb
.Pp
.ds \[] \fBx
test text \fR after define string with \e[]