Closed zarniwhoop73 closed 4 months ago
The reason that dvisvm-2.13 was working with the current gs library is that it was compiled against an older default libgs (9.53).
Anyway, the solution is to upgrade to dvisvgm 3.2.1: https://github.com/vectorgraphics/asymptote/issues/434
This issue can presumably now be closed.
Well, John, I'm glad it works for you. I have not yet found the missing piece of the jigsaw. I tried dvisvgm-3.2.1 after raising this issue, no change. Then I looked at fedora and found two patches for ghostscript fixing issues there, one of which sounded relevant. My ghostscript was vanilla, but after patching it I still get the failure.
I was comparing to the 10.03.0 prerelease of ghostscript but dvisvgm 3.2.1 also works for me with gs 10.02.1.
Unfortunately, I can't reproduce the error here. Could you isolate the actual issue with dvisvgm and provide a corresponding DVI/EPS file? As I don't know much about the internals of asy, I can't really tell what might go wrong during the conversion.
Here's an example comparing 3.0.3, which fails, and 3.2.1, which works (for me):
dvisvgm --version dvisvgm 3.0.3 [wizard: ~/camp master] dvisvgm test.dvi The old, written in PostScript, PDF interpreter has been removed entirely. You should cease using -dNEWDPF as it has no effect npre-processing DVI file (format version 2) processing page 1 graphic size: 100.876875pt x 100.876875pt (35.454167mm x 35.454167mm) output written to test.svg 1 of 1 page converted in 0.388851 seconds
dvisvgm --version dvisvgm 3.2.1 [wizard: ~/camp master] dvisvgm test.dvi pre-processing DVI file (format version 2) processing page 1 graphic size: 100.876875pt x 100.876875pt (35.454167mm x 35.454167mm) output written to test.svg 1 of 1 page converted in 0.0585079 seconds
Ok, thanks for the example file. As far as I can tell from the console output, both versions produce the same SVG file but dvisvgm 3.0.3 triggers the GS warning because it uses -dNEWPDF. This option was removed with GS 10.01.0 only after the release of dvisvgm 3.0.3. It shouldn't have any effect here, though, because there's nod PDF processing involved in this example. I suppose, Ken's issue seems to be something different.
I see; the -dNEWDPF error message confused me.
As Ken reports, there still is an issue with dvisvgm 3.2.1:
[test.ps.gz](https://github.com/mgieseki/dvisvgm/files/14502394/test.ps.gz)
dvisvgm test.ps -E
processing EPS file
PostScript error: undefined in finddeviceOperand stack:
5 --nostringval-- --nostringval-- --nostringval-- imgdev jpeg
I do have a sphere_.pdf, presumably created during asy's rendering stage which either eventually generates the error message, or else succeeds and is then followed by the error message.
My dvisvgm was initially 3.2, now 3.2.1. My ghostscript is now 10.02.1 patched with two patches from fedora, PostScript-Fix-selectdevice.patch which looked hopeful (gs bug 707310), and txtwrite-device-needs-to-countdown-the-device-on-tex.patch which merely suppresses a debug message - but since I was patching I figured I'd take both.
I see John has now posted test.ps which also shows a similar failure but without creating a test_.pdf file.
Aargh, that's another incompatible GS "improvement". They silently removed operator finddevice
in GS 10.02.1:
https://bugs.ghostscript.com/show_bug.cgi?id=707307
I guess I need to find a workaround for it. At the moment, I can only suggest to use an older GS.
Unfortunately, I currently have no idea how to work around this issue. When I was looking for ways to implement the bitmap extraction back then, I already noticed that PS operator setpagedevice
threw an error when called inside a redefinition of another operator. finddevice
, on the other hand, worked flawlessly, so I used that one.
As I don't know why setpagedevice
doesn't work here, I opened a ticket in the GS bug tracker:
https://bugs.ghostscript.com/show_bug.cgi?id=707645
Let's hope, they could provide some helpful feedback.
I've implemented a workaround that works so far with my (few) tests. Could you please test the latest version from the master branch too? If there are no things missing, I'll create a new dvisvgm release.
Hi Martin, Good news: commit 40ff350d327d41f492beb1e9b0a88053822e5939 works perfectly for me. A new release containing this workaround will be much appreciated by the TL community.
Thanks so much,
-- John
On Wed, Mar 6, 2024 at 11:58 AM Martin Gieseking @.***> wrote:
I've implemented a workaround that works so far with my (few) tests. Could you please test the latest version from the master branch too? If there are no things missing, I'll create a new dvisvgm release.
— Reply to this email directly, view it on GitHub https://github.com/mgieseki/dvisvgm/issues/264#issuecomment-1981681376, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADE6N3GFTAVPCX6PNXL3KBLYW5YN3AVCNFSM6AAAAABEHRH42KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGY4DCMZXGY . You are receiving this because you commented.Message ID: @.***>
That commit [https://github.com/mgieseki/dvisvgm/commit/40ff350d327d41f492beb1e9b0a88053822e5939] works nicely for me as well. Thank You so much to both of you.
Great, thank you both for the feedback. I'm preparing a hotfix release and will upload it later today.
I just uploaded dvisvgm 3.2.2 that contains the latest changes. If you find any further issues, please let me know.
I thought this was a problem with asymptote and raised it at [https://github.com/vectorgraphics/asymptote/issues/434] but it now looks like a problem in dvisvgm-3+.
Brief background: I have some test scripts to exercise 3D asy outside of latex (create pdf, png, rotatable html, and svg output). At some point in the last six months the svg output failed. Yesterday I went back to an old system and discovered that creating an svg from asy worked IFF I used libgs-10.01 (or, I assume, earlier versions).
The MWE used a file from asymptote's examples/ directory (can be run as 'asy fielname -f svg') and John Bowman now says that using old dvisvgm-2.13 worked for him with current gs, but last year's dvisvgm-3.0.3 breaks.
I'm using dvisvgm-3.2.