Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases

[Wolfgang Glunz]

Hi Thorsten,

The issue is caused because pdftops creates a PostScript file which
contains the whole drawing as a single bitmap image (don't know why).
And bitmap images are not supported by pstoedit for the mpost format.

Regarding
" (which is NOT documented, purifyeps says it takes PostScript only as
input but since it relies on pstoedit, this seems to work) then I get a
result file that at least looks the same with gs."

Yes - pstoedit handles PDF nicely because GhostScript handles them like
PostScript file. Well - at least up to version 9.55. From version 9.56
on, the default handling of PDF files in GhostScript changes to use a
new PDF interpreter. And that one does not interact at all with
pstoedit. There is still an option to use the old PostScript base PDF
interpreter, but that is not guaranteed to be maintained forever.

Best Regards

Wolfgang

Am 03.04.2022 um 03:43 schrieb Thorsten Glaser:
> Dixi quod…
>
>> Package: pstoedit
>> Version: 3.78-1
>> Followup-For: Bug #1008280
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008280
> for the full story and reproducer.
>
> With the help of http://www.calvina.de/pstoedit/pstoedit.htm#section_69
> I may have found a workaround (which indicates a bug in pstoedit’s ps
> handling, per the instructions there).
>
> The bug appears when doing:
>
> $ inkscape -D --export-filename=test1.pdf --export-type=pdf \
>      --export-pdf-version=1.4 teckids_logo_image.svg
> $ pdftops -eps test1.pdf test1-a.eps
> $ purifyeps test1-a.eps test1-b.eps
>   which calls
>    pstoedit -ssp -f mpost -fontmap /usr/share/pstoedit/mpost.fmp \
>      test1-a.eps tmp.mp
>
> If I instead run…
> $ purifyeps test1.pdf test3.eps
> (which is NOT documented, purifyeps says it takes PostScript only
> as input but since it relies on pstoedit, this seems to work) then
> I get a result file that at least looks the same with gs.
>
> So something weird happens in pdftops from poppler-utils :/
> (Huh. I’d have thought pdftops is part of ghostscript… apparently not.)
>
> Looking at this more: pdftops -eps test1.pdf test1a-$distro.eps
> followed by purifyeps test1a-$distro.eps test1b-$distro.eps
>
> This fails on all chroots I tested: stretch 0.48.0-2+deb9u4,
> buster 0.71.0-5, bullseye 20.09.0-3.1, sid 22.02.0-3
>
> Another experiment, getting rid of poppler-utils in the middle:
>
> -----BEGIN cutting here may damage your screen surface-----
> $ pdf2ps test1.pdf test4-1.ps
> $ ps2eps test4-1.ps
> Input files: test4-1.ps
> Processing: test4-1.ps
> Rendering with existing %%BoundingBox: 0 0 234 187
> Calculating Bounding Box...ready. %%BoundingBox: 0 0 234 187
> Creating output file test4-1.eps ... ready.
> $ purifyeps test4-1.eps test4-2.eps
> pstoedit: version 3.75 / DLL interface 108 (built: Jan  2 2020 - release build - g++ 9.2.1 20191130 - 64-bit) : Copyright (C) 1993 - 2020 Wolfgang Glunz
> This is MetaPost, version 2.00 (TeX Live 2020/Debian) (kpathsea version 6.3.2)
> (/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
> (/usr/share/texlive/texmf-dist/metapost/base/plain.mp
> Preloading the plain mem file, version 1.005) ) (/tmp/purifyeps-PG1MlbvQ.mp )
> Transcript written on purifyeps-PG1MlbvQ.log.
> purifyeps: No such file or directory (/tmp/purifyeps-PG1MlbvQ.1)
> -----END cutting here may damage your screen surface-----
>
> Looks like it’s not poppler at fault here though :~
>
> Any idea? (Also, I can’t find where pstoedit’s bugtracker is.)
>
> bye,
> //mirabilos