bug-groff
[Top][All Lists]
Advanced

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

PDFPIC misbehaves if called two times in a row


From: joerg van den hoff
Subject: PDFPIC misbehaves if called two times in a row
Date: Sun, 31 Jul 2022 11:28:50 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

currently considering to slowly migrate to gropdf as my default output device 
(from grops + ps2pdf)
and gave PDFPIC a first try. bad luck so far ... consider this `ms' document in 
a file named `tt.trf':

.LP
foo
.PDFPIC aitail.pdf
.LP
bar
.PDFPIC fig2.pdf

(both pdf files are PDF 1.4)

I see two issues when formatting this with either grops or gropdf.

1.
using `groff -U -ms -Tps tt.trf' issues a warning

troff: tt.trf:6: warning: numeric expression expected (got 'f')

where the "f" turns out to be the first letter of the second file name (in the example above "figs.pdf"). furthermore, the formatted document than does contain two copies of the
*first* pdf file ("aitail.pdf" in the above document, i.e. there are now two 
identical
figures in the resulting ps-file although the two eps-files "secretly" 
generated by
PDFPIC in this case (to make it work with grops) are distinct and correct.

I guess there is something askew in the PDFPIC internal logic how to map 
everything to PSPIC?
in any case the above does not work with groff 1.22.4 on OSX currently for me. 
any ideas?

2.
the second issue is maybe known(?) but surprises me. namely:
using `groff -U -ms -Tpdf tt.trf' to directly generate pdf-formatted output 
works w/o
the above-mentioned warning and erroneous duplication of first picture but in 
contrast to PSPIC
it seems that PDFPIC does not make room for the imported picture: both imported
pictures overlap massively and vertical position difference is that 
(apparently) corresponding
to the

.LP
bar

before second picture is imported. so it seems PDFPIC does not move vertical 
position at all?
this is of course undesirable from the user's perspective :). I would not even 
know how
to sensibly and easily compute myself the vertical space needed...
so regarding the second issue: is this "expected behaviour" and if so, how is 
the recommendation
to automatically make sufficient room for the imported picture?

currently both issues look like bugs to me, so I do hope it's the correct list 
to post this ...

best,
joerg



reply via email to

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