See my comment about this plugin requiring you to "Restructure ePub to Sigil Norm" be run by Sigil before launching the plugin.
No all epubs follow the old Sigil norm for how folders should be used inside an epub. Even Sigil itself no longer has that limitation.
Quote:
Originally Posted by philja
I've been looking deeper into why the plugin produced code does not display the images between <svg> tags in my W10 box and I've found the answer.
This is a typical piece of code produced by the plugin:
Code:
<div>
<svg
xmlns="http://www.w3.org/2000/svg"
height="100%" width="100%"
preserveAspectRatio="xMidYMid meet" version="1.1"
viewBox="0 0 710 698"
xmlns:xlink="http://www.w3.org/1999/xlink">
<image width="710" height="698" xlink:href="../Images/Pictures/circle-Fsh.gif"/>
</svg>
</div>
Compare this with the original code:
Code:
<div class="Image">
<img alt="Relatives" src="Pictures/circle-Fsh.gif" width="65%"/>
</div>
This epub file shows signs in the opf file that I have passed it through Calibre (which I used to do in the early days) and I was using Sigil 1.1.0.
Although the opf shows the images as having a path Pictures/image, Sigil shows 'Images' as the folder name in the browser pane. How does that magic happen?
The plugin sticks '../Images/' on the front of whatever image source link it finds in the file.
I have found other epubs which do not have any indication of Calibre in the opf but the images are in a directory 'images' (no capital letter) and the plugin produces the source link as
Code:
<image width="724" height="721" xlink:href="../Images/images/image021.gif"/>
whereas it was originally :
Code:
<img alt="Image57" src="images/image021.gif" width="65%"/>
Did earlier versions of Sigil label the Images directory 'images' ?
In any case, as soon as the link to the image is corrected, it displays correctly. |