Asymptote to SVG conversion fails

[rbeezer]

On Ubuntu 18.04 my binary of dvisvgm is built in such a way that using asy -outformat svg ... fails. So an mbx conversion to SVG will fail for me.

I can successfully run a conversion from the command line, by running mbx -vv ... to get the right temporary directory and the right command, and then build by-hand a command with libgs="", as suggested at the end of the Asymptote issue. But that is not realistic for bulk conversions.

No idea if adding that empty option would cause harm for those without problems.

For complete details wade through:

https://github.com/vectorgraphics/asymptote/issues/33

[rbeezer]

Better solution: in home directory create file

.asy/config.asy

with contents

import settings;
libgs="";

Note that semi-colons are missing from the post https://github.com/vectorgraphics/asymptote/issues/33

[sean-fitzpatrick]

Also note that outformat svg will fail for any Asymptote file that loads graph3. There is no direct output of 3D Asymptote to 2D svg. Instead we have to output to pdf and then convert to svg.

[rbeezer]

So asy will not create any output with graph3 loaded and -outformat svg. Does anything bad enough happen to totally disrupt the mbx script?

Other than there is no file to copy? We know how to avoid that Python error. Sounds like we need to add that?

Am I right that right now a PTX source with an asy/graph3 used with mbx svg output is going to blow up? We first need to do no harm. ;-)

[sean-fitzpatrick]

There's an earlier thread on one of the Google groups where Michael Doob helped me figure this out, back before WebGL was an option.

I can't remember if mbx fails, or just hangs. (I think it might be the latter: with verbose output it gets to "converting foo.asy to foo.svg" and halts until I kill it with control + C.)

So I had been running mbx with pdf as the outformat, and then using a bash script to convert the PDF to svg.

In other words, I don't think this will make things worse.

[rbeezer]

Aah, but it is worse when using new asymptote, which is really not out there yet. In other words we have not been supporting graph3 anyway? So, only Sean is messed up right now?

[sean-fitzpatrick]

Testing with latest Asymptote: running mbx on a file with a couple of 2D images (first line: import graph;) using mbx -vv -c asy -f svg -d ... and things work out fine.

If I drop a 3D image in there (first line: import graph3;) mbx halts and spits out a traceback with an IO error (No such file or directory: foo.svg)

Changing -f svg to -f html lets mbx run all the way through.

I did make one mistake: the fallback to svg when using html as the outformat was missing the subroutine that looks for png files that are generated for graphs with colour/shading. Pushing that change momentarily.

[sean-fitzpatrick]

From my point of view: graph3 support was never there for svg output. It still isn't. Maybe an author still wants svg because it's more 'lightweight' than WebGL. But John made some major improvements in resource utilization for us.

For asy images that don't use graph3, we get the same results whether the outformat is svg or html.

The question is, do we want mbx to 'properly' support svg output for 3D asy? If yes, we need to:

• detect presence of the import graph3; line in an asy component
• redirect the -f svg option to -f pdf before it's passed to the asy binary
• run pdf2svg on the pdf output before copying to the output directory.

Or we add documentation (and possibly a warning message) to let users know that direct output to svg isn't supported for 3D asy, and recommend html as the preferred outformat. (Or recommend that the user output to pdf and then convert to svg after mbx is done.)

[sean-fitzpatrick]

Of course, all of the above does not address the issue you initially noted with dvisvgm. But perhaps it's useful to note that I'm also on Ubuntu 18.04, and the only thing that isn't installed from the standard repositories is Asymptote 2.62.

So maybe this is fixed upstream with newer Asymptote?

[rbeezer]

Thanks for the PNG fix. I wasn't sure about that. Merge in a bit.

detect presence of the import graph3; line in an asy component

I've been thinking about this. When the XSL spreadsheet rips out the asy code, we can detect "graph3", and pass a flag ("2D", "3D"?) into the Python list mbx receives. Would that be sufficient to condition on? Ideally, we'd only like to fail on "file not found" when the author's source code is messed up, not when mbx passes the wrong flags/arguments.

Finer points. We don't want an author to use a variable like mygraph33 and so get fooled. XSL strategy:

• convert newlines, commas, semi-colons to spaces (easy)
• apply normalize-space() which trims leading whitespace and consolidates runs of spaces into one space (easy)
• restore a single leading space and a single trailing space (easy)
• now search on graph3, a string with spaces on either end (easy)

I don't know asy syntax that well, does that sound like the correct first step to separate out every legitimate graph3 into a graph3 and not get any false positives?

I'd be happy to update the stylesheet to report 2D and 3D, and send it to you for further work on the Python routines?

I think, generally, we should do as much as we possibly can for each output format, without errors. If the above is enough information, we just don't try to build a version we can't build. But maybe we need to allow an author to say "I just want a 2D picture of this 3D thing in my online output"?

[rbeezer]

Aah, that'd be nice. I mean to experiment with the binary, but likely can't get to it for a bit.

Anyway, this is here just to be informational for anybody else who gets bit. I don't intend to try to provide any kind of fix, so let's not sweat old Ubuntu with old Asy. ;-)

Of course, all of the above does not address the issue you initially noted with dvisvgm. But perhaps it's useful to note that I'm also on Ubuntu 18.04, and the only thing that isn't installed from the standard repositories is Asymptote 2.62.

So maybe this is fixed upstream with newer Asymptote?

[sean-fitzpatrick]

Maybe we ask Michael Doob for an opinion? Who else uses Asymptote?

If you can bypass having xsl convert semicolons right away, each line in Asymptote ends with one. So requiring the presence of 'graph3;' should avoid false positives.

[rbeezer]

Maybe we ask Michael Doob for an opinion? Who else uses Asymptote?

Only Canadians, it seems. ;-) Yes, pinging @mdoob

If you can bypass having xsl convert semicolons right away, each line in Asymptote ends with one. So requiring the presence of 'graph3;' should avoid false positives.

A space before the semi-colon is legal?

Can you go import graph3, foo;?

[mdoob]

I haven't thought about this for a while. My recollection is that the -f svg produced no output and then mbx barfed because of an attempted read.

Trying to support the -f svg option by scanning author input sounds inherently error prone to me. Is there any was for asymptote to tell us if the author loaded the graph3 package?

[sean-fitzpatrick]

All the examples I've seen have each import on a separate line, but I can't rule out multiple imports on one line. (I've been too busy getting other people's Asymptote code to work to learn how to make my own!)

Maybe we trust that an author is going to know if they've written any 3d images, ans give advice based on that?

We've adjusted the pdf command (adding -noprc) to get 3D pdf output working (previously we'd just get an empty file).

Getting svg for 3d images will involve detecting the import of graph3, and adding an extra processing step to convert from to svg. (I suppose the latter isn't so bad; we already do it for TikZ.)

An author who knows they have 3d content should be advised to stick to either pdf or html for output format, and then convert the former to svg if they need that format.

For those who aren't sure, or don't read the advice: can we just do a similar thing to the if, then, else I added for HTML?

Only this time, something like:

if os.path.exists(asysvg):
    shutil whatever copy the damn file
else:
    print a message about direct conversion to svg being unsupported for 3d graphs... Check your source for import of graph3

[rbeezer]

Most of this discussion has been replaced by work on #1275.