Re: PDFPIC misbehaves if called two times in a row

[joerg van den hoff]

hi deri,

thank you for looking into this!

question: the pdfpic.tmac you've send is supposed to work if I include it at top of my document 
(e.g. the fragment tt.trf) so that it overrules the pdfpic that is probably loaded previously?

well, I have done that (include at top), but then it does only generate empty output files (both, 
with grops as well as gropdf) :(

am I missing something?

br/joerg

On 31.07.22 17:47, Deri wrote:
> On Sunday, 31 July 2022 10:28:50 BST joerg van den hoff wrote:
> > 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
>
> Hi Joerg,
>
> I think the pdf output works Ok with the current version in git, but the git
> version had a different problem with the postscript output.
>
> I think I have found the fix please can you test with this version, which I
> will commit soon.
>
> Cheers
>
> Deri