Groff-1.22.1: No pdfdocdir created

[Matt Burgess]

Hi,

I'm getting the following error when running 'make install' from
groff-1.22.1:

for f in mom-pdf.pdf; do \
rm -f /usr/share/doc/groff-1.22/pdf/$f; \
ln
-s /usr/share/doc/groff-1.22/examples/mom/$f /usr/share/doc/groff-1.22/pdf/$f; \
done
ln: failed to create symbolic link
'/usr/share/doc/groff-1.22/pdf/mom-pdf.pdf': No such file or directory
make[3]: *** [install_data] Error 1

That's the following snippet:

contrib/mom/Makefile.sub (160):

for f in $(PDFDOCFILE); do \
rm -f $(DESTDIR)$(pdfdocdir)/$$f; \
ln -s $(exampledir)/mom/$$f $(DESTDIR)$(pdfdocdir)/$$f; \
done

Now, the only reference to creating pdfdocdir I can see is in the
following:

contrib/pdfmark/Makefile.sub (105):

install_pdfdoc:
-test -d $(DESTDIR)$(pdfdocdir) \
|| $(mkinstalldirs) $(DESTDIR)$(pdfdocdir)

But my log output, attached, doesn't show that snippet being executed at
all. Any help debugging this further please would be very much
appreciated.

Thanks,

Matt.

[Werner LEMBERG]

> I'm getting the following error when running 'make install' from

> groff-1.22.1: [...]

Actually, there are a lot of errors already during `make' which should
cause an abort. Reason are missing fonts, but it's not clear to me
how to handle this situation gracefully. I've CCed Deri, and
hopefully he can find a proper solution.

If you want a quick fix, please install the URW PostScript fonts
together with its metric files (this is, fonts like `URW Gothic' or
`URW Bookman' which usually have file names like `a010035l.{pfb,afm}'
or `b018015l.{pfb,afm}).

Deri, in Matthew's original report
(http://lists.gnu.org/archive/html/bug-groff/2012-12/msg00016.html)
you can find the complete log file. It seems that the failure of
finding the URW fonts breaks gropdf completely so that it can't find
*any* font.

Another (minor) issue is warning messages like

Warning: line 28:
Unable to locate font 'URWGothicL-Demi!a010015l.pfb' on the given path(s)

The string `URWGothicL-Demi!a010015l.pfb' doesn't denote a valid font
name.


Happy New Year!

Werner

[Deri James]

Hi Werner,

First the reported problem that the $(pdfdocdir) has not been created before
MOM tries to install mom-pdf.mom. The reason is because this is normally
created during the installation of the original pdfmark macro and pdfroff, but
since no ghostscript was found during configure the installation of pdfroff is
skipped. From the make log:-

configure: WARNING: missing program:

The program `gs' cannot be found in the PATH.
Consequently, groff's PDF formatter (pdfroff) will not work properly;
therefore, it will neither be possible to prepare, nor to install,
documentation in PDF format.

So this particular problem is due to missing ghostscript (not missing
ghostscript fonts), and the "solution" is to create the directory in both
places (pdfmark and mom).

Now the missing font problems, the reason why gropdf completely falls when
fonts are missing is due to the euro font definitions in europs.tmac. If you
remove the lines like:-

.do fschar AB \[Eu] \f[EURO]\N'1'

Then all works correctly (the missing fonts elicit a warning if a missing font
is referenced in a troff document, the same as using an unknown font in grops,
and the font remains unchanged). I'm not sure of the best way of dealing with
this. Is there a way of detecting if a particular font exists before setting
up the \[Eu] definitions? If not then I need to generate a separate
europdf.tmac while I am checking what fonts are available during the make.
What do you think.

After doing the manual adjustment to europs to only define symbols for the 14
base font which are set up if the URW fonts are not found, all works as it
should, and gropdf works fine using the base fonts only.

During make the warnings like

Warning: line 28:
Unable to locate font 'URWGothicL-Demi!a010015l.pfb' on the given path(s)

Are "correct" it is looking for either URWGothicL-Demi or a010015l.pfb - older
versions of ghostscript used to include the font with the more verbose name,
but newer versions do not (the fonts are compiled into the executable) so you
need the separate URW fonts which use the DOS 8.3 naming restriction.

What do you think is best (regarding the euro dfinitions)?

Cheers

Deri

[Deri James]

On Monday 31 Dec 2012 12:53:59 Werner LEMBERG wrote:
> I've CCed Deri, and
> hopefully he can find a proper solution.

Attached is a patch which fixes the problem (tested by "hiding" the
ghostscript program and fonts and running configure).

The fix is to europs.tmac which temporary turns off missing font warnings and
restores the original font after defining all euro characters. There is also a
fix to create the pdf document directory before the mom install tries to
create a link in it, in case "gs" was missing during the configure so pdfroff
is not installed. Finally there are a couple of bug fixes to gropdf not
related to the missing font problems.

Cheers

Deri

[Werner LEMBERG]

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


Deri,


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
test

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
p1
f:2: warning: can't find character `t'
f:2: warning: can't find character `e'
f:2: warning: can't find character `s'
V12000
H72000
n12000 0
x trailer
V792000
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())
return;
else
tok.next();
tok.next();
}

`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
test

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
`.ds'...


Werner

[Ingo Schwarze]

Hi Werner,

Werner LEMBERG wrote on Fri, Jan 04, 2013 at 11:13:12AM +0100:

> 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
> `.ds'...

Even though mandoc(1) is not a real troff(1) implementation,
given that it implements *some* roff(7) requests commonly occurring
in man(7) and mdoc(7) documents, let me provide a brief answer:

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

But i agree that, if somebody attempts to map an undefined character
escape sequence to something else, printing an error message and
ignoring the mapping attempt altogether makes more sense than printing
the error message and executing the definition right away, once.

Yours,
Ingo

[Werner LEMBERG]

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

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

> But i agree that, if somebody attempts to map an undefined character
> escape sequence to something else, printing an error message and
> ignoring the mapping attempt altogether makes more sense than
> printing the error message and executing the definition right away,
> once.

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). However, in conditional, automated runs it's
not that easy, as the posted log demonstrates.


Werner

[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[]

[Werner LEMBERG]

> Is there a way of detecting if a particular font exists before
> setting up the \[Eu] definitions?

I've somehow missed this question. Yes, there is, for example

.do if F ABI \
. do fschar ABI \[Eu] \f[EURO]\N'1'

This is the way to go I think (regardless of a fix for groff's
`skip_line' problem).

> Warning: line 28:
> Unable to locate font 'URWGothicL-Demi!a010015l.pfb' on the given path(s)
>
> Are "correct" it is looking for either URWGothicL-Demi or
> a010015l.pfb

*I* fully understand that but Joe User might be irritated due to the
exclamatation mark. Maybe this can be improved to something like
this:

Warning: line 28:
Unable to locate font `URWGothicL-Demi' on the given path(s).
(searched font files: `URWGothicL-Demi.pfb', `a010015l.pfb')


Werner

[Deri James]

Here's patches for europs and BuildFoundries.pl

BuildFoundries looks for either pfa OR pfb versions of the fonts, so I have
left the extensions off the font names in the warning.

Cheers

Deri

[Werner LEMBERG]

> Here's patches for europs and BuildFoundries.pl

Applied, thanks.


Werner