nbsphinx
nbsphinx copied to clipboard
spatialaudio
Wrong Image in HTML
Summary
When I have multiple images in a Jupyter notebook, I end up with the wrong image displayed in the final html file generated by sphinx/nbsphinx. I've created a minimal reproducing example here. The images below show the output of the example. Note that the large letters are images.
Rendered on GitHub
Final HTML
Other notes
- This appears to occur both with nbsphinx from anaconda and the master branch
- See here for my enviroment
- This likely related error is output during compilation:
- WARNING: Duplicate substitution definition name: "image0".
If this is indeed a bug and not an error on my part, I'd be happy to help with the fix if I could get some direction on where to start hunting.
Thanks for the detailed report!
That's indeed strange ... I just tried your example project on my computer and it works, the "A" and "B" images are displayed correctly.
The warning message you mentioned is strange, I don't know why there should be anything called "image0", the image names should be unchanged.
I realized that you don't have "pandoc" in your environment. Probably you have an old and/or broken version of Pandoc installed locally?
If that's not it, could you please try to remove all unneeded packages from your environment and also remove all unneeded extensions from conf.py?
I realized that you don't have "pandoc" in your environment. Probably you have an old and/or broken version of Pandoc installed locally?
This ended up being the answer!
I had version 2.1 of pandoc which was released on Jan 7th 2018, which seems surprisingly up to date. Since conda had several older versions of pandoc available, I decided to screen those before testing the one slightly newer version. It turns out that I get the error with any version of pandoc in the v2.x.x line but I can correctly compile the html files with versions between v1.15.2 - 1.19.2.
tl;dr: It wasn't that my pandoc was too old, but rather that it was too new.
Thanks for your help with debugging!
It's great that you found the error, but the bad news is that in the future more people will use pandoc 2.x. I'm re-opening this issue.
I'm not sure if that's bug, but it's definitely an unexpected feature. We'll either have to fix pandoc or we'll have to find some work-around.
Can you please check, just to be sure, what pandoc creates?
You can simply run this:
pandoc -f markdown -t rst
... then type in
... and finally hit Ctrl+D.
Version 1.19.2
$ pandoc --version; pandoc -f markdown -t rst
pandoc 1.19.2
Compiled with pandoc-types 1.17.0.4, texmath 0.9, skylighting 0.1.1.2
Default user data directory: /Users/tbm/.pandoc
Copyright (C) 2006-2016 John MacFarlane
Web: http://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.
.. figure:: A.png
:alt:
Version 2.1
$ pandoc --version; pandoc -f markdown -t rst
pandoc 2.1
Compiled with pandoc-types 1.17.3, texmath 0.10.1, skylighting 0.5.1
Default user data directory: /Users/tbm/.pandoc
Copyright (C) 2006-2018 John MacFarlane
Web: http://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.
|image0|
.. |image0| image:: A.png
I've asked at the pandoc mailing list: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/pandoc-discuss/BnBnux7trXs.
I got an answer with a suggestion that I can't really use: https://groups.google.com/forum/#!msg/pandoc-discuss/BnBnux7trXs/5arJtzdEAwAJ
However, it looks like this happens only if the "alt" text of the image is empty. As long as something is in there, it should be fine.
Sometime in the past i got the same issues. It's about how sphinx/nbsphinx rename images and copy these into the _build directory. Unfortunately, I can not reproduce the bug with my current versions, but I'll tell you what happened
I have this markdown snipet in my notebooks ..about 200! notebooks
what happens when these notebooks are converted into html files, the Egg.png will be copied into build/_images as Egg0.png / Egg1 ..... Egg200.png With http://nbsphinx.readthedocs.io/en/0.2.18/subdir/toctree.html all runs fine....image counter goes from 0 to 199. ...with an other version i got only image0.png from every notebook Egg.png file. see #157/#152
@martintb how are the image named in build/_images ...normal0.png or A0.png , B0.png? @mgeier if the image is only within the notebook, how is the name for this image chosen?
@rddaz2013 I'm not sure what you mean by "only within the notebook":
if the image is only within the notebook, how is the name for this image chosen?
Do you mean if the image is in the output area of a code cell?
In this case a prefix is chosen by nbsphinx based on the notebook file name
https://github.com/spatialaudio/nbsphinx/blob/1cfef1188fdb63b424fc69b89b1b27c4f55f9e81/src/nbsphinx.py#L653
To this prefix, nbconvert adds two numbers: the cell number and the number of the output within this cell (there might be multiple outputs).
Or do you mean if the image is saved as a cell attachment?
This doesn't work yet, see #114.
Or do you mean something else?
if the image is only within the notebook, how is the name for this image chosen?
if the image is not linked per markdown...only a image output cell...like the matlibplot's
@rddaz2013
if the image is not linked per markdown...only a image output cell...like the matlibplot's
Then the name of the file is chosen with unique_key, as mentioned above.
The Bug ist back...or something like that.
If in my ipynb file i have two inputcells...with
In[1]: 
In[2]: 
then I get two images ONLY B.png in the HTML/PDF Output...like @martintb said.
The workaround was..
However, it looks like this happens only if the "alt" text of the image is empty
In[1]: 
In[2]: 
is working..
If in my ipynb file i have ONE inputcells...with
In[1]: 
then I get two images A and B (like in the work around) in the HTML/PDF Output, but if the image are too big no 'newpage' in the Latex-Output.
I've been spotting this problem again recently I though I fixed it by adding alt text as per https://github.com/ouseful-oer/openlearn-molworld/commit/06661c3848f41f9bb3ccff9f4a30b72a3352a208, but it seems that if the link text is the same across multiple images, that also breaks thinks... (so a fix is to add a randomiser or counter to alt text... :-(
Apparently, this has been fixed in https://github.com/jgm/pandoc/commit/f268ae30350e3d94e57e58e5a543d3292d204b83, now we just have to wait for a new Pandoc release.
That would be great
Pandoc can work with ipynb files itself now but it is limited.
Am Sa., 25. Apr. 2020 um 11:27 Uhr schrieb Matthias Geier < [email protected]>:
Apparently, this has been fixed in jgm/pandoc@f268ae3 https://github.com/jgm/pandoc/commit/f268ae30350e3d94e57e58e5a543d3292d204b83, now we just have to wait for a new Pandoc release.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spatialaudio/nbsphinx/issues/162#issuecomment-619350057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7V7TCFETBGDSZO2GKGZS3ROKUJ7ANCNFSM4EMWOF3A .
The fix has been released in Pandoc version 2.10.
Sadly, this is not completely true, see also #500.
It is true that Pandoc has indeed been fixed, but there remains a bug in nbsphinx!
It works fine for multiple images that are in the same Markdown cell, but it still does not work if the images are in separate Markdown cells (as in the example mentioned above).
The work-around is, as before, to use a unique alt value for each image, e.g.
What are the downsides embedding the image? eg using the route taken by the --to html_embed handler provided by nbextensions/export_embedded extension?
I also note that @betatim has seen a related or complementary local relative path issue in his pandoc free notebook-as-pdf converter?
@psychemedia
What are the downsides embedding the image?
I don't know ... the "download image" feature in the browser becomes awkward?
Jupyter already supports embedding images, but this wouldn't solve the problem anyway, see #500.