Closed mdoob closed 3 years ago
I know this is for the sample article but have you tried running mbx with svg output over some 3D graphs? I could try running it over the 3D graphs in APEX to see how that comes out. Overkill maybe, but John seemed to think it should work fine if everything is reasonably up to date
Here is my "standard" MWE for 3d tests:
import three;
size(6cm);
size3(2cm,1cm,1cm);
draw(unitbox);
If you use this with asy -f svg
, you get an svg file which contains the line
<image x='56.413252' y='53.798257' width='172' height='159.980075' xlink:href='cube_0.png'/>
and this works fine if the file cube_0.png, created by asy, is in the same directory. Since mbx doesn't put the png file(s) in place, the svg fails to display properly.
A propos to this PR, asymptote-contour.svg does the same thing, and that is precisely why I rolled my own to make the svg file that is included in the c245f5d commit.
Doesn't mbx
have a subroutine that checks for the png files and copies them if they're there?
for diagram in diagrams:
asydiagram = diagram[0]
# can condition processing on diagram[1]
# which is a string: '2D' or '3D'
if outformat == 'source':
shutil.copy2(asydiagram, dest_dir)
elif outformat == 'html':
filebase, _ = os.path.splitext(asydiagram)
asyout = "{}.{}".format(filebase, outformat)
asysvg = "{}.svg".format(filebase)
asypng = "{}_*.png".format(filebase)
asy_cmd = [asy_executable, '-outformat', outformat, asydiagram]
_verbose("converting {} to {}".format(asydiagram, asyout))
_debug("asymptote conversion {}".format(asy_cmd))
subprocess.call(asy_cmd, stdout=devnull, stderr=subprocess.STDOUT)
if os.path.exists(asyout) == True:
shutil.copy2(asyout, dest_dir)
else:
shutil.copy2(asysvg, dest_dir)
# Sometimes Asymptotes SVGs include multiple PNGs for colored regions
for f in glob.glob(asypng):
shutil.copy2(f, dest_dir)
else:
filebase, _ = os.path.splitext(asydiagram)
asyout = "{}.{}".format(filebase, outformat)
asypng = "{}_*.png".format(filebase)
asy_cmd = [asy_executable, '-noprc', '-offscreen', '-batchMask', '-outformat', outformat, asydiagram]
_verbose("converting {} to {}".format(asydiagram, asyout))
_debug("asymptote conversion {}".format(asy_cmd))
subprocess.call(asy_cmd, stdout=devnull, stderr=subprocess.STDOUT)
shutil.copy2(asyout, dest_dir)
# Sometimes Asymptotes SVGs include multiple PNGs for colored regions
for f in glob.glob(asypng):
shutil.copy2(f, dest_dir)
Maybe there's a bug in this part of the code?
My recollection is that the SVG created by asy makes assumptions about the location of the PNG file that are inaccurate when the two files live in a directory below the directory with the page including the image.
Do the mbx drill, put everything in place, then use your browser to open just the SVG image.
At least that is how I remember it before I disappear to grade final exams. mbx definitely looks for a PNG and tries to place it correctly.
On 5/12/20 11:31 AM, sean-fitzpatrick wrote:
Doesn't |mbx| have a subroutine that checks for the png files and copies them if they're there?
|for diagram in diagrams: asydiagram = diagram[0] # can condition processing on diagram[1] # which is a string: '2D' or '3D' if outformat == 'source': shutil.copy2(asydiagram, destdir) elif outformat == 'html': filebase, = os.path.splitext(asydiagram) asyout = "{}.{}".format(filebase, outformat) asysvg = "{}.svg".format(filebase) asypng = "{}_.png".format(filebase) asy_cmd = [asy_executable, '-outformat', outformat, asydiagram] _verbose("converting {} to {}".format(asydiagram, asyout)) _debug("asymptote conversion {}".format(asy_cmd)) subprocess.call(asy_cmd, stdout=devnull, stderr=subprocess.STDOUT) if os.path.exists(asyout) == True: shutil.copy2(asyout, dest_dir) else: shutil.copy2(asysvg, dest_dir) # Sometimes Asymptotes SVGs include multiple PNGs for colored regions for f in glob.glob(asypng): shutil.copy2(f, destdir) else: filebase, = os.path.splitext(asydiagram) asyout = "{}.{}".format(filebase, outformat) asypng = "{}_.png".format(filebase) asy_cmd = [asy_executable, '-noprc', '-offscreen', '-batchMask', '-outformat', outformat, asydiagram] _verbose("converting {} to {}".format(asydiagram, asyout)) _debug("asymptote conversion {}".format(asy_cmd)) subprocess.call(asy_cmd, stdout=devnull, stderr=subprocess.STDOUT) shutil.copy2(asyout, dest_dir) # Sometimes Asymptotes SVGs include multiple PNGs for colored regions for f in glob.glob(asypng): shutil.copy2(f, dest_dir) |
Maybe there's a bug in this part of the code?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/1275#issuecomment-627517157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLM4RNPM7QY6D4UBRXVXDRRGIZHANCNFSM4M6MIWFA.
I made a fresh copy of the mathbook repo and reran xsltproc on the sample-article followed by mbx using asy with the -f html option.
First of all, using version 2.65 of asymptote will now clear up the problem with the Riemann surface. It looks beautiful.
Next, I found a (start for a) solution to the problem with the contour plot. It is in the graphics.html file generated by xsltproc. The diff between to original and new graphics.html files is given below, but in summary:
<object data="images/asymptote-contour.
html" id="asymptote-contour" width="600" height="600">
is changed to
<object data="images/asymptote-contour.
svg" id="asymptote-contour" width="600" height="600">
4c4
< <!--* on 2020-05-13T12:23:52-05:00 *-->
---
> <!--* on 2020-05-13T09:32:40-05:00 *-->
351c351
< <figure class="figure figure-like" id="figure-asymptote-contour-plot"><div class="image-box" style="width: 100%; margin-left: 0%; margin-right: 0%;"><object data="images/asymptote-contour.html" id="asymptote-contour" width="600" height="600"><img src="images/asymptote-contour.svg" style="width: 100%; height: auto;" alt=""></object></div>
---
> <figure class="figure figure-like" id="figure-asymptote-contour-plot"><div class="image-box" style="width: 100%; margin-left: 0%; margin-right: 0%;"><object data="images/asymptote-contour.svg" id="asymptote-contour" width="600" height="600"><img src="images/asymptote-contour.svg" style="width: 100%; height: auto;" alt=""></object></div>
I can see where these lines get generated in the mathbook-html.xsl file, but I'm hesitant to add my own fix since I'm not sure what other things would be affected.
And furthermore, the source for asymptote-contour.asy is
import graph;
import palette;
size(10cm,10cm,IgnoreAspect);
real f(real x, real y) {
return 0.9*pow10(2*sin(x/5+2*y^0.25)) + 0.1*(1+cos(10*log(y)));
}
scale(Linear,Log,Log);
pen[] Palette=BWRainbow();
bounds range=image(f,Automatic,(0,1),(100,100),nx=200,Palette);
xaxis("$x$",BottomTop,LeftTicks,above=true);
yaxis("$y$",LeftRight,RightTicks,above=true);
palette("$f(x,y)$",range,(0,200),(100,250),Top,Palette,
PaletteTicks(ptick=linewidth(0.5*linewidth())));
Question: import graph
is not import graph3
, so why the choice of html output in extract-asymptote?.
I'm going to try running mbx with svg output on APEX Calculus. (All asymptote graphs are 3D graphs there though.)
As I understand the mbx
script, it:
<asymptote>
component in the source and writes it to a file in a temp directory.<macros>
section at the top of your PreTeXt file at the top of each file.asy
with the specified options on every file in that temp directoryimages
folder.So I think (but could be wrong) that it's the asy
binary that's deciding whether or not a given Asymptote figure should be rendered as html or svg when you run it with the -f html
option.
So what I learned today is that version 2.65 (in fact, I think 2.62 will do) is good enough to run mbx -c asy -f html
and get a successful run through APEX, with all files outputting to HTML, except for a small number of non-3D asymptote (yes, it turns out these do exist in APEX) that get converted to SVG automagically.
But if I run mbx -c asy -f svg
I run into trouble: we need version 2.66 of Asymptote, and dvisvgm
at version 2.9.1 to get direct svg output from 3D Asymptote.
I spent awhile tonight fighting to get asymptote to compile from the github source. Every time I think I've got it, it turns out I was missing some library and it doesn't work as expected. I'll try again tomorrow!
Sean --
Could you try the with same experiment the asymptote-contour.asy attached?
So what I learned today is that version 2.65 (in fact, I think 2.62 will do) is good enough to run
mbx -c asy -f html
and get a successful run through APEX, with all files outputting to HTML, except for a small number of non-3D asymptote (yes, it turns out these do exist in APEX) that get converted to SVG automagically.
mathbook-html.xsl
generates HTML output of the PTX that will embed the Asymptote image as an object
whose @data
is the HTML file. Then a fallback is contained in the object
which uses an img/@src
that is an SVG file.
So, is mbx -c asy -f html
"good enough" to create all the Asymptote images for HTML output? We may need to do something else for an author who wants all 2D versions of every diagram/figure, even if they are described as 3D.
The mbx
script does nothing more for mbx -c asy -f html
than call asy
with -outformat html
. -f pdf
and -f svg
are run by the same stanza, so perhaps these need to be split and adapted separately.
Yes, I think for most use cases, we want to run with HTML output -- we get SVGs for free on figures where there is no 3D content. But maybe you need SVG for ePub? And Alex likes to have each image available in multiple formats.
We might need different commands for PDF and SVG, because we have to pass different options. For PDF we probably want -noprc
. For SVG the default image quality isn't great, so we want something like -render=4
.
I've been able to get 2.66 to compile from source but it isn't working quite right. In particular, the -offscreen
option isn't working for me. I think this is an Ubuntu thing (in particular, the Mesa graphics libraries.)
@mdoob - what "extra" did you need to do to make the "contour" plot? Just a newer version of asy
, or something else?
It appears to have the two "gradient" images embedded directly as base64 (one PNG, one JPG) within the single SVG file, where formerly the SVG "linked in" two external PNG files. The new scheme would be a big improvement.
Here is my output running Asymptote 2.66 on asymptote-contour.svg
:
contour plot
This was on my laptop where I'm running Ubuntu 18.04. I'm able to compile Asymptote just fine here. But I know John was asking about having dvisvgm
at version 2.9.1. That's not possible on 18.04 because it requires a newer version of libc6.
I'll try on my desktop in a bit.
Hi Sean --
Did you get the same result with -f svg and -f html? My problem was with the former working and the latter not.
From: sean-fitzpatrick notifications@github.com Sent: May 14, 2020 2:13:37 PM To: rbeezer/mathbook Cc: Michael Doob; Mention Subject: Re: [rbeezer/mathbook] Asy fixes (#1275)
Caution: This message was sent from outside the University of Manitoba.
Here is my output running Asymptote 2.66 on asymptote-contour.svg: contour plothttp://www.cs.uleth.ca/~fitzpat/asymptote-contour.svg
This was on my laptop where I'm running Ubuntu 18.04. I'm able to compile Asymptote just fine here. But I know John was asking about having dvisvgm at version 2.9.1. That's not possible on 18.04 because it requires a newer version of libc6.
I'll try on my desktop in a bit.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rbeezer/mathbook/pull/1275#issuecomment-628835025, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAVJL7VLF4APSIUFIV7IUYTRRQ7GDANCNFSM4M6MIWFA.
Yes, I got the same result. Running asy asymptote-contour.asy -f html
gives me the terminal output:
warning [htmltosvg]: html output requested for 2D picture; generating svg image instead...
and I get what appears to be the same SVG as before.
@mdoob - what "extra" did you need to do to make the "contour" plot? Just a newer version of
asy
, or something else?It appears to have the two "gradient" images embedded directly as base64 (one PNG, one JPG) within the single SVG file, where formerly the SVG "linked in" two external PNG files. The new scheme would be a big improvement.
Here is where I see us now: when running mbx with -f html, the svg file and png files that appear in the images directory are correct, in the sense that they can display properly. The problem is that the html as generated is unable to to do this (the diff between the working and failing ones is in a previous comment (about 10 back). One extension is changed from html to svg.
Just to repeat:
<object data="images/asymptote-contour.html" id="asymptote-contour" width="600" height="600">
needs to be changed to
<object data="images/asymptote-contour.svg" id="asymptote-contour" width="600" height="600">
in order for the figure to appear.
I also tried adding the attribute dimension="2", but it made no difference.
In the HTML for APEX Calculus (most recently generated about a week ago) each Asymptote figure appears like the following (this is the very first Asymptote figure in the book):
<figure class="figure figure-like" id="fig_cross1">
<div class="image-box" style="width: 47%; margin-left: 26.5%; margin-right: 26.5%;">
<object data="images/img_cross1.html" id="img_cross1" width="282" height="282">
<img src="images/img_cross1.svg" style="width: 100%; height: auto;" alt="">
</object>
</div>
As I understand it, this looks first for the HTML, and if that is missing, it uses SVG.
I'm pretty sure my HTML source was similar last fall before Asymptote 2.62 came out. Back then I was running mbx
to produce PDF output for each figure and then using a shell script (courtesy of Michael) to convert all the PDF to SVG. And images showed up.
But yes -- I can confirm what Michael is saying: if I remove the HTML file (or rather, rename it), the SVG is not being used as fallback. I just get an empty image.
But if I right-click and select view image, the SVG is there.
I'm confused by the diff @mdoob posted above. First, the timestamps look out-of-order (older one is leaving). And the *.html
version is what should be currently produced.
The checks on the import
have no effect on files like graphics.html
.
When I build with this PR applied everyting looks fine - in other words, SVG fallbacks are working.
I'm confused by the diff @mdoob posted above. First, the timestamps look out-of-order (older one is leaving). And the
*.html
version is what should be currently produced.
It took me some time to find a single change that would put everything right. I saved the corrected graphics.html and reran xsltproc to be sure that diff would report exactly one significant change, and so the file that works is older than the one that doesn't.
The checks on the
import
have no effect on files likegraphics.html
.When I build with this PR applied everyting looks fine - in other words, SVG fallbacks are working.
Yes, the svg and png files show up properly in the images directory. The problem is that the graphics.html files doesn't read them. I think that asy and mbx are doing the right thing. It appears that during the extraction of the asymptote code from the xml file, the source is being interpreted as a 3D figure.
To add a little more fuel to the fire:
running mbx -vv -f html -c asy -d ./images sample-article.xml
yields
MBX: #####################################################
MBX: converting asymptote-lever.asy to asymptote-lever.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-lever.asy']
MBX: converting asymptote-contour.asy to asymptote-contour.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-contour.asy']
MBX: converting asymptote-lever-integral.asy to asymptote-lever-integral.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-lever-integral.asy']
MBX: converting asymptote-surface.asy to asymptote-surface.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-surface.asy']
MBX: converting asymptote-workcone.asy to asymptote-workcone.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-workcone.asy']
MBX: converting asymptote-lever-solo.asy to asymptote-lever-solo.html
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'html', 'asymptote-lever-solo.asy']
So every call to asy uses -f html. Now mbx has received '2D' or '3D' to indicate the dimension of the figure. Shouldn't that be used at this point?
It wasn't clear to me if mbx was now receiving that information. But is that even necessary? I think the point is that Asymptote can make that decision. We just run mbx with html as the output type.
Asymptote is going to successfully convert every image. Some will become html, some will become svg.
The mbx script calls asy
, then it calls shutil
to move the output to the images folder. We just need an if/else for the shutil
step: if the html exists, move it. Else, move the svg.
It wasn't clear to me if mbx was now receiving that information. But is that even necessary? I think the point is that Asymptote can make that decision. We just run mbx with html as the output type.
Asymptote is going to successfully convert every image. Some will become html, some will become svg.
Ok. If that's the plan, let's forget 2D/3D in extract-asymptote.xsl. Just use -f html on everything.
The mbx script calls
asy
, then it callsshutil
to move the output to the images folder. We just need an if/else for theshutil
step: if the html exists, move it. Else, move the svg.
Sounds like a plan!
The main reason I'm trying to figure out svg is that someone might want to force svg format for figures that would otherwise be html. So we want to be able to run mbx -c asy -f svg
and have that exit successfully when there are 3D figures present.
It seems like Asymptote 2.66 should support this. Although John mentioned in email that -offscreen
isn't supported any more. I need to find out if that's going to be an issue.
The checks on the import have no effect on files like graphics.html.
I added the 2D/3D information to extract-asymptote.html
when I thought somebody was going to use it in the Python script.
The mbx script calls asy, then it calls shutil to move the output to the images folder. We just need an if/else for the shutil step: if the html exists, move it. Else, move the svg.
I believe this is already there.
Yes, I put it there in that initial pull request to add support for html output from Asymptote. Though I'm not sure if that PR we ever fully merged.
For the various output formats, I think we're at:
PDF: works on all figures. HTML: works on all figures (but 2D gets converted to svg) SVG: currently fails on 3D but will work on all figures with next Asymptote release
I'm not sure there's much demand for other formats (EPS?).
We're maybe a year out from being able to do a clean mbx run using default versions in a stable Linux distro. But for those willing to pull in a few programs at higher version numbers we should be there by next week.
OK, positive result. I am currently enjoying watching a shell script blast through 309 asy files generated from APEX Calculus ptx. All but a few are 3D, and I'm generating SVG.
The render=4
option gives nice output, but annoying if you're doing 300 diagrams: each time one is processed, a window pops up that steals focus. (Typing a message is fun: get in a few keystrokes, window comes, window goes, few more keystrokes, repeat.)
A slight modification of a suggestion from John Bowman does the trick: I'm running:
asy foo.asy -f svg -tex xelatex -render=0
The render=0
option is very experimental according to John. But I got a smooth run. Everything outputs to SVG, with no accompanying PNG files. And the SVG looks good.
About to try this with mbx.
Note however that SVG and PDF will need different command line options, so we will have to tweak the mbx script a bit more -- I think -- to treat these separately.
One bit of bad news: it's not working with mbx and I can't figure out why. (I'm using the current mbx in pretext/dev, not the one Rob is experimenting with, but with a line modified to include the SVG command.) I get:
MBX: extracting Asymptote diagrams from /home/sean/github/APEXCalculusPTX/ptx/index.ptx
MBX: converting img_cross1.asy to img_cross1.svg
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'svg', '-tex xelatex', '-render=0', 'img_cross1.asy']
Traceback (most recent call last):
File "/home/sean/github/mathbook/script/mbx", line 1511, in <module>
asymptote_conversion(args.xml_file, args.xmlid, output_dir, 'svg')
File "/home/sean/github/mathbook/script/mbx", line 139, in asymptote_conversion
shutil.copy2(asysvg, dest_dir)
File "/usr/lib/python2.7/shutil.py", line 153, in copy2
copyfile(src, dst)
File "/usr/lib/python2.7/shutil.py", line 96, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'img_cross1.svg'
But if I cd
into the tmp directory created by mbx and do
asy -outformat svg -tex xelatex -render=0 img_cross1.asy
the svg is created as expected.
So I'm not sure why asy
is failing when it's called by mbx
.
John Bowman suggests not using render=0
because it can have unintended consequences.
So maybe we want something like
asy -f svg -tex xelatex -render=4 foo.asy
John told me that adding the iconify
option would prevent windows from popping up but this did not succeed in my case.
Going back to the the graphics.html file, I extracted every reference to asymptote/image:
<object data="images/asymptote-lever.html" id="asymptote-lever" width="600" height="600">
<img src="images/asymptote-lever.svg" style="width: 100%; height: auto;" alt="Moments on a lever">
<object data="images/asymptote-contour.svg" id="asymptote-contour" width="600" height="600">
<img src="images/asymptote-contour.svg" style="width: 100%; height: auto;" alt="">
<object data="images/asymptote-lever-integral.html" id="asymptote-lever-integral" width="480" height="480">
<img src="images/asymptote-lever-integral.svg" style="width: 100%; height: auto;" alt="">
<object data="images/asymptote-surface.html" id="asymptote-surface" width="240" height="240">
<img src="images/asymptote-surface.svg" style="width: 100%; height: auto;" alt="">
<object data="images/asymptote-workcone.html" id="asymptote-workcone" width="300" height="326">
<img src="images/asymptote-workcone.svg" style="width: 100%; height: auto;" alt="">
<object data="images/asymptote-lever-solo.html" id="asymptote-lever-solo" width="600" height="600">
<img src="images/asymptote-lever-solo.svg" style="width: 100%; height: auto;" alt="Moments on a lever">
Here are the files generated by mbx:
-rw-rw-r-- 1 mdoob mdoob 40583 May 14 19:29 asymptote-contour_0.png
-rw-rw-r-- 1 mdoob mdoob 2646 May 14 19:29 asymptote-contour_1.png
-rw-rw-r-- 1 mdoob mdoob 44486 May 14 19:29 asymptote-contour.svg
-rw-rw-r-- 1 mdoob mdoob 20429 May 14 19:29 asymptote-lever-integral.svg
-rw-rw-r-- 1 mdoob mdoob 13447 May 14 19:29 asymptote-lever-solo.svg
-rw-rw-r-- 1 mdoob mdoob 13447 May 14 19:29 asymptote-lever.svg
-rw-rw-r-- 1 mdoob mdoob 211584 May 14 19:29 asymptote-surface.html
-rw-rw-r-- 1 mdoob mdoob 83054 May 14 19:29 asymptote-workcone.html
In each case when graphics.html is unchanged, mbx uses the data=
file with an extension of html and the src=
filewith the extension svg. This works fine for each case except the asymptote-contour one, where the html extension needs to be replaced by svc to get the proper display. The failing case is the only one that uses auxiliary png files.
I have no explanation for this phenomenon. Any ideas?
But if I cd into the tmp directory created by mbx and do asy -outformat svg -tex xelatex -render=0 img_cross1.asy the svg is created as expected. So I'm not sure why asy is failing when it's called by mbx.
Are you absolutely sure that mbx is using (via its configuration file) the same version of asymptote and you're using by hand?
From: sean-fitzpatrick notifications@github.com Sent: May 15, 2020 12:00:08 AM To: rbeezer/mathbook Cc: Michael Doob; Mention Subject: Re: [rbeezer/mathbook] Asy fixes (#1275)
Caution: This message was sent from outside the University of Manitoba.
One bit of bad news: it's not working with mbx and I can't figure out why. (I'm using the current mbx in pretext/dev, not the one Rob is experimenting with, but with a line modified to include the SVG command.) I get:
MBX: extracting Asymptote diagrams from /home/sean/github/APEXCalculusPTX/ptx/index.ptx
MBX: converting img_cross1.asy to img_cross1.svg
MBX-DEBUG: asymptote conversion ['asy', '-outformat', 'svg', '-tex xelatex', '-render=0', 'img_cross1.asy']
Traceback (most recent call last):
File "/home/sean/github/mathbook/script/mbx", line 1511, in
But if I cd into the tmp directory created by mbx and do asy -outformat svg -tex xelatex -render=0 img_cross1.asy the svg is created as expected.
So I'm not sure why asy is failing when it's called by mbx.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rbeezer/mathbook/pull/1275#issuecomment-629027297, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAVJL7W33AS5LCMSMMNPWZLRRTD5RANCNFSM4M6MIWFA.
To be honest -- no, not absolutely. But the mbx config file just has asy=asy
, and doing asy --version
reports 2.66.
As for the svg with the auxiliary png not displaying: I can't speak to the cause, but I did notice that if I remove one of the html images (for APEX) and replace it with the SVG (and associated PNGs), nothing shows up. But if I right click and choose View Image, it's there.
@mdoob I think I found the answer on stack overflow
The SVG has to be self-contained or Chrome blocks it for privacy reasons.
One suggestion is to replace <img src="foo.svg"/>
with <embed src="foo.svg"/>
I can confirm that this works. See http://www.cs.uleth.ca/~fitzpat/apex-calculus/sec_disk.html
The first image was WebGL html. I uploaded an SVG that contains an auxiliary PNG, and renamed the html. Reloading the page results in an empty image, but if I open the image in a new tab, I can see it.
I then hand-edited the HTML source for this section, and changed img
to embed
. The image now shows up as expected.
Original:
<figure class="figure figure-like" id="fig_cross1">
<div class="image-box" style="width: 47%; margin-left: 26.5%; margin-right: 26.5%;">
<object data="images/img_cross1.html" id="img_cross1" width="282" height="282">
<img src="images/img_cross1.svg" style="width: 100%; height: auto;" alt="">
</object>
</div>
updated:
<figure class="figure figure-like" id="fig_cross1">
<div class="image-box" style="width: 47%; margin-left: 26.5%; margin-right: 26.5%;">
<object data="images/img_cross1.html" id="img_cross1" width="282" height="282">
<embed src="images/img_cross1.svg" style="width: 100%; height: auto;" alt="">
</object>
</div>
This is a long shot, but you could put the complete path to the working version of asymptote in mathbook/user/mbx.cfg.
The same svg nondisplay phenomenon happens on my home desktop (ubuntu 18.04 + asymptote 2.65) using firefox. However, one thing you mentioned turned out to be interesting: if I right-click on the screen area where the image is supposed to be, it pops up correctly in a different window. So the image is really loaded, but is not visible.
Yes -- it's blocked by the browser (both Chrome and Firefox).
But if you change <img src="foo.svg/>
to <embed src="foo.svg/>
the image will show up fine.
OK, progress. Things are starting to make more sense to me.
Look at the contents of the "contour plot" SVG attached in this pull request. There are two images (one PNG, one JPEG) inside the file as base64. So no associated images linked in.
@mdoob How much special did you do to make this? In other words, is it just an updated asymptote
or dvisvgm
that is making this happen? (I've lost track.)
Suggestion: in line 5849 of mathbook-html.xsl
, what happens if you change <xsl:element name="img">
to <xsl:element name="embed">
?
If I'm reading things right, that will use embed
instead of img
to load the SVG fallback, and the SVG will appear even if there's an auxiliary PNG.
It's my turn with kids so I have to test later. But with Asymptote 2.6.6 and dvgsvgm
at 2.9.1 I'm pretty sure I don't get the extra PNG files if I run asy -f svg -tex xelatex -render=4 foo.asy
Started with an fresh branch and was able to confirm that your change img -> embed (good spelling!) works.
I think the svg you're looking at, Rob, comes from using pdf2svg. We seem really close to making this obsolete. The version using dvisvgm looks much better.
While Sean is with his kids, I've scheduled a haircut (someone in the future will surely wonder why this might be in any way noteworthy). (:-))
OK, spent a long time reading through all this. Seems there are two things to do:
embed
versus img
for a fallback SVG in HTML output files where an Asymptote image appears. I'd make a beta for browser testing before merging this.mbx
to support -f svg
. And this will depend on very recent releases. But might fix the error Sean got with a small change.When we are confident about changes, it would help if @sean-fitzpatrick were to write down the best asy command lines (switches) for html/svg, pure-svg, and PDF.
In the good news/bad news department: (bad news first)
mbx
is still failing on me when I try to run asy
with SVG output and I don't know why. (I tried putting the full path to asy
in mbx.cfg
with the same result. But I also don't have any other asy
version installed.)asy -f svg -render=4 asymptote-contour.asy
I get two auxilary PNG files. But if I add in the option -tex xelatex
I get a single SVG with no added PNG files.I suspect the reason is that I've got the most recent dvisvgm
installed. But I'm not entirely sure. (John could probably tell me but I've sent enough his way this week.)
It's possibly mbx
is not working because I'm on older hardware (AMD A10-6800K APU from 2013) with open source graphics drives. John mentioned that the -iconify
option, which suppresses the rendering window, doesn't work on some older graphics configurations. Maybe mbx
doesn't like that window popping up?
I made a change to mathbook-html.xsl following Sean's suggestion. Here is the diff
mdoob@Z97N-WIFI:~$ diff mathbook-html.xsl.*
5784c5784
< <xsl:element name="embed">
---
> <xsl:element name="img">
All the figures displayed correctly. I looked at the logs and did get a number of 404s for html files, but later all the svg and png files came in as expected (200 return code).
Thanks, Michael. I'll make a beta version soon, so folks can hit it with a variety of browsers. img
, object
, embed
seem to have a checkered history.
Beta here:
https://pretextbook.org/beta/2020-05-16-asymptote/graphics.html
Old 2-D Riemann surface. Figure 9.12 is 3D HTML via object
. I cannot see 9.12 when viewing locally, I do see it in this hosted version.
If @mdoob and @sean-fitzpatrick both report success here, then I can put it on -dev for wider testing.
Sean and I went down the local/hosted version problem earlier. To make a long story short,
your browser won't let you load a local html file as a security measure. Running
python3 -m http.server
will let you load the web address localhost:8000 and in this context you can view your files.
You can add a different port number as a command line option.
The graphics in the sample article all show up for me. The non-interactive 3D image seems like it could be higher quality but I don't think that's a PreTeXt issue.
I get the same results on both Chrome and Firefox on Ubuntu 18.04.
Looks like the png got loaded instead of the svg. What do your logs tell you?
Looking at the page source (or using the inspector), I think the embed option is including the SVG source. Then the SVG loads the PNG.
Commits here by @mdoob have been repackaged, keeping everything as-is. Thanks very much for the flexibility of a separate commit for the contour plot, which at one point I did consider dropping. Nice use of git. I moved the 3D surface into a subsection with the 3D cone. And added documentation, including keyboard controls from @mdoob on -dev
, as an accessibility feature.
I'm going to keep this open. If I got recommened asy
command lines (-render
, -tex
, etc.) I could spruce up the mbx
script while tip-toeing around the other refactoring there. Then close this.
Thanks for all the good work on this one. We're getting there.
This pull request addresses the missing asymptote Figures 9.9 and 9.11 in Section 9.3. The added svg files will now display properly. The Riemann surface actually uses WebGL, so maybe it is slightly out of place. The contour plot is a bit more of a problem. I generated it myself rather that using mbx, so it does show what PreTeXt can do, albeit not using the standard route. If this makes you uncomfortable, I included that file with a separate commit so that it is easy to abandon. Now that it has my attention, I'll use the next few days to see how dvisvgm might be adapted.
Cheers, Michael