bug-groff
[Top][All Lists]
Advanced

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

Re: PDFPIC misbehaves if called two times in a row


From: Deri
Subject: Re: PDFPIC misbehaves if called two times in a row
Date: Sun, 31 Jul 2022 16:47:38 +0100

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

Attachment: pdfpic.tmac
Description: Text Data


reply via email to

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