Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
> >Failing on some inputs is not a justification for a `serious` severity. > > *Silently* failing, i.e. saying you succeed but not doing so, > however is Regardless of severity, does anyone have any good ideas for fixing this? Patches welcome! Feel free to just upload a fix if you have the urge. Please, let's make this moot.
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
Antonio Terceiro dixit: >Failing on some inputs is not a justification for a `serious` severity. *Silently* failing, i.e. saying you succeed but not doing so, however is, in my book. If it at least aborted giving the error code, I’d accept that somewhat more easily. >Thus, I am downgrading this bug to normal. Not playing severity pingpong here but please reconsider. Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
Control: severity -1 normal Failing on some inputs is not a justification for a `serious` severity. Thus, I am downgrading this bug to normal. signature.asc Description: PGP signature
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
Hi Wolfgang, > The issue is caused because pdftops creates a PostScript file which > contains the whole drawing as a single bitmap image (don't know why). Oh, ouch. So, bug in poppler after all? >> $ pdf2ps test1.pdf test4-1.ps >> $ ps2eps test4-1.ps Hm, not just poppler? test4-1.ps has a large encoded blob I think is a bitmap as well… so ghostscript does the same. > And bitmap images are not supported by pstoedit for the mpost format. Right, of course. > 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 Ah, ouch, so the workaround will work on bullseye and older only. I need to convert to PS first, but all PDF to PS converters introduce this bug (bitmap present). Hrm… it appears that, for those files whose source is SVG (not PDF, we do have several of that as well), I might be able to export PS from Inkscape. Or do the stable-and-older workaround, first. Do the poppler and/or ghostscript maintainers perhaps have an insight in why this PDF is converted to PS with embedded bitmap? (Even adding -dLanguageLevel=3 to pdf2ps does not make it better.) bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
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
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
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 -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
Package: pstoedit Version: 3.78-1 Followup-For: Bug #1008280 X-Debbugs-Cc: t...@mirbsd.de This is reproducible on sid. It also occurs on buster, although with a different failure mode: -BEGIN cutting here may damage your screen surface- $ purifyeps test1-a.eps test1-b.eps pstoedit: version 3.73 / DLL interface 108 (built: Jul 11 2018 - release build - g++ 7.3.0 - 32-bit) : Copyright (C) 1993 - 2018 Wolfgang Glunz Error: /undefined in .makeoperator Operand stack: false rectfill rectfill --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1991 1 3 %oparray_pop 1990 1 3 %oparray_pop 1978 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1033/1123(G)-- --dict:0/20(G)-- --dict:216/300(L)-- --dict:1033/1123(G)-- Current allocation mode is global Current file position is 14841 GPL Ghostscript 9.27: Unrecoverable error, exit code 1 PostScript/PDF Interpreter finished. Return status 256 executed command : gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS "/tmp/psinbqMIs2" The interpreter seems to have failed, cannot proceed ! purifyeps: The following command failed with exit code 1: pstoedit -ssp -f mpost -fontmap "/usr/share/pstoedit/mpost.fmp" "test1-a.eps" "/tmp/purifyeps-hn9Vq58x.mp" -END cutting here may damage your screen surface- stretch looks similar to bullseye though: -BEGIN cutting here may damage your screen surface- $ purifyeps test1-a.eps test1-b.eps pstoedit: version 3.70 / DLL interface 108 (built: Oct 11 2016 - release build - g++ 6.2.1 20161215 - 32-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz This is MetaPost, version 1.9991 (TeX Live 2016/Debian) (kpathsea version 6.2.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-nUGj2O9a.mp ) Transcript written on purifyeps-nUGj2O9a.log. purifyeps: No such file or directory (/tmp/purifyeps-nUGj2O9a.1) -END cutting here may damage your screen surface- -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages pstoedit depends on: ii ghostscript 9.55.0~dfsg-3 ii libc62.33-7 ii libpstoedit0c2a 3.78-1 ii libstdc++6 12-20220319-1 pstoedit recommends no packages. Versions of packages pstoedit suggests: pn xfig | ivtools-bin | tgif | transfig -- no debconf information
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
Package: pstoedit Version: 3.75-1 Severity: serious Justification: unusable by some users X-Debbugs-Cc: t...@mirbsd.de, hill...@web.de, debian-tex-ma...@lists.debian.org Control: affects -1 purifyeps I’ve noticed purifyeps (which is needed for Tₑχ/LᴬTᴇΧ to process .eps files) fails on some inputs and could trace this down to pstoedit’s output for the broken files to be much too small. I’m attaching the full testcase with sources and all intermediate files. This is on a bullseye system (plus two debugging prints in purifyeps which Hilmar should just ignore comparing his output to mine). The full screen log of the process (from SVG via PDF to EPS) follows, for a sampling of two files, one of which succeeds, the other doesn’t. Very noticeable, besides the test-1.mp size, is “x: 99 y: 99 x: 0 y: 0” (failure) vs. x: 0 y: 0 x: 22 y: 13 (success). $ inkscape -D --export-filename=test1.pdf --export-type=pdf --export-pdf-version=1.4 teckids_logo_image.svg (inkscape:25600): dbind-[1;33mWARNING[0m **: [34m22:09:15.196[0m: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files $ pdftops -eps test1.pdf test1-a.eps $ purifyeps test1-a.eps test1-b.eps D: running: pstoedit -ssp -f mpost -fontmap "/usr/share/pstoedit/mpost.fmp" "test1-a.eps" "/tmp/purifyeps-V7yHSU2q.mp" 1>&2 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 D: running: echo X | mpost /tmp/purifyeps-V7yHSU2q.mp 1>&2 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-V7yHSU2q.mp ) Transcript written on purifyeps-V7yHSU2q.log. purifyeps: No such file or directory (/tmp/purifyeps-V7yHSU2q.1) D: tempbase=/tmp/purifyeps-V7yHSU2q $ pstoedit -v -ssp -f mpost -fontmap "/usr/share/pstoedit/mpost.fmp" test1-a.eps test-1.mp 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 loading plugins from /usr/lib/x86_64-linux-gnu/pstoedit using suffix: .so loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so completed successfully loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so completed successfully loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so completed successfully loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so completed successfully loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so completed successfully path to myself: /usr/bin/pstoedit pstoedit home directory : /usr/bin pstoedit data directory : /usr/share/pstoedit Loading fontmap from /usr/share/pstoedit/mpost.fmp loading system specific fontmap from /usr/share/pstoedit/windows.fmp Looking up where to find the PostScript interpreter. GS not set, trying registry for common/gstocall nothing found so far, trying default: gs Value found is:gs Looking up specific options for the PostScript interpreter. First trying registry for common/GS_LIB still not found an entry - now trying GS_LIB env var. GS_LIB not set Value returned: now calling the interpreter via: gs -dDELAYBIND -dWRITESYSTEMDICT -dESTACKPRINT -dNODISPLAY -dDELAYSAFER -dNOEPS "/tmp/psine2b20s" GPL Ghostscript 9.53.3 (2020-10-01) Copyright (C) 2020 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Now checking the temporary output got 1 page(s) from /tmp/psoutFgTRot x: 99 y: 99 x: 0 y: 0 now postprocessing the interpreter output postprocessing the interpreter output finished closing dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so not really closing dynamic library because of pthread problem under Linux - contact author for details or check dynload.cpp from pstoedit source code /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so destroying Dynloader
