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
