[Top][All Lists]

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

Re: [Groff] pdfroff broken?

From: Keith MARSHALL
Subject: Re: [Groff] pdfroff broken?
Date: Tue, 14 Mar 2006 14:52:55 +0000

Larry Kollar wrote, quoting me:
>> Larry Kollar wrote, quoting himself:
>>>> I did "make clean," updated, did a configure & make, and everything
>>>> seems to be working properly now. Sorry for the false alarm.
>>> But then a trivial change to broke it again.
>>  That isn't one of the distributed files;  do you mean
>>  If yes, what trivial change broke it?  Was it a `make'
>> that failed?  If not, what was the failing command?
> You're right, I need to not post when I'm frustrated. :-P


> The change I made was to define .HD at the top of the file as follows:
> .de HD
> .  pdfmark /Label (\\n% /PAGELABEL
> ..

Isn't that missing a closing parenthesis?  Should it not be
   .  pdfmark /Label (\\n%) /PAGELABEL ?

> The intent was to test my theory about setting PDF's page numbers to 
> match the current page number (i.e. if you're in the TOC, the page 
> number should be "iii" or something similar).

I've tried adding your HD definition in my copy of, (with
the closing parenthesis in place).  While I can see the /PAGELABEL
marks in the groff intermediate output, (but strangely, no "i" label
for the TOC), I see no visible effect on the document display, in
Acrobat Reader v6.

> Then I did "make" and it gave me the same "gs 8.53 failed" error as I 
> had before I reloaded.  ...

A missing closing parenthesis in the pdfmark code could well cause such
an error, for it will confuse the gs parser, but...

> ...  Backing out the change and "make"ing gave me the same error.
> It's like you can only do it once.

This is very strange.  I have noticed that, on Win32, if the original
PDF remains open in Acrobat Reader, then gs fails because it cannot
open the output file, (Reader seems to keep an exclusive lock on it);
however, this has never been a problem for me under GNU/Linux.

>>> I guess I should bite the bullet, install it, and see if that takes
>>> care of it.
>> Perhaps.  But it really should run within the build directory, if the
>> environment is appropriately configured.
> Agreed. If I get a chance, I'll figure out how to make gs/ps2pdf get 
> ultra-chatty about what it's doing and hack pdfroff accordingly.

Hmm.  I don't use ps2pdf in pdfroff;  I run gs directly.  If it helps,
the latest patch I applied in CVS, (last Thursday), should keep the
intermediate files.  If you can find the cause of the problem, patches
will be most welcome.


reply via email to

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