Plugin to insert and wrap an image with SVG

[roger64]

Thank you

[Thomas_AR]

It seams the plugin does not insert the svg.xhtml page where you choose to insert (after, before, etc), but several pages above.
Anybody has experienced the same behaviour?
Using latest Sigil and Plugin.
Thanks

[DiapDealer]

Originally Posted by Thomas_AR

Anybody has experienced the same behaviour?
Using latest Sigil and Plugin.
Thanks

Yes. Inserting at the Beginning or End work fine. The Insert Before|After functionality seems to be a bit off, however. Not sure if that's new, or if it's always been that way.

And looking at the code, I see why it doesn't work, but I'm not certain how quick or easy the fix would be. If there was a one-line change I could give to correct it, I would. You'll probably have to wait on the plugin creator to notice this.

Suffice to say: the code should probably be using bk.spine_iter() instead of bk.text_iter. And sorting the xhtml files before loading them int0 the combo box is a mistake.

[DiapDealer]

Actually, it's not that difficult. It would take a minor reworking to make it more robust, but someone should be able to get by with changing line 194 of plugin.py from:

for id, href in self.bk1.text_iter():

to:

for id, linear, href in self.bk1.spine_iter():

And then commenting out line 199 (plugin.py again) that does the sorting.
From:

self.cbXhtmlList=self.natural_sort(self.cbXhtmlList) #Sort the list of images

to:

#self.cbXhtmlList=self.natural_sort(self.cbXhtmlList) #Sort the list of images

[Thomas_AR]

Thanks i will give that a try.

[CalibUser]

I have updated the plugin to version 1.6.1 to correct the bug mentioned by Thomas_AR. The bug was introduced in version 1.6.0

Thanks to DiapDealer for spotting the bug.

[enterpr1se]

Is it normal the svg import image with a smaller width and hight?
I have a photo 1000px x 1511px
But the viewBox will become "0 0 260 400"
and the image size will become width="260" height="400"

[enterpr1se]

Originally Posted by CalibUser

I may look at this as a possibility when I get time and if others request this feature.

At present the selected image is displayed so that you can check whether you have selected the correct one; also, you can insert this image at any required position in the ePub. If multiselections became available, then in the first instance, it would not display all the files selected and the files would all be inserted at the same position in the epub file.

I want this function too.
It will much easier to make comic Epub

[roger64]

Hi

This is a proposal.

One example coming from an ePub3 produced by LibreOffice.
The original cover file is described with an item in both the toc.xhtml and the toc.ncx.

If you change this original file with a SVG wrapper using this fine plugin, and then delete the original file, the new SVG wrapper file name is not updated in both tocs.

epubcheck reports then that the original file is missing and you have to change the name of this file manually.

It could concern, not only the cover images, but some images within the ePub as well.

Could this last task (updating the tocs) be performed automatically?

[DiapDealer]

I'm not sure that makes sense, Roger. This plugin creates a new xhtml file out of an image you specify. It doesn't change any existing files and it has no preconceived notions about what you want to do with the newly created one (SVG wrapped images can occur anywhere on an epub). Once this new xhtml file has been created, it's up to you (the user) to decide if it is to be used as the cover page, or if it needs to be included in any html toc or nav documents, or what-have-you.

If you're looking to modify an existing cover page in an epub, I suggest using the built-in Tools->Add Cover feature of Sigil. It will take an image of your choosing, wrap it in an SVG and either create a new cover.xhtml (if no cover-page is already defined), or it modifies an existing cover page (if one is already defined). All pre-existing links would remain intact.

[roger64]

@DiapDealer

Thanks for your reply. It was just a proposal, if there had been an easy way to do it...

When the cover page file name is present in both tocs (it does not happen all the time, it depends of the tool used to produce en ePub) and needs to be changed, I'll rather use the Sigil built-in tool that I did not have considered.

[AlanHK]

Originally Posted by roger64

Hi
If you change this original file with a SVG wrapper using this fine plugin, and then delete the original file, the new SVG wrapper file name is not updated in both tocs.

When I'm replacing a page with a simple image with an SVG one, I use the plugin to make a new file, then copy all the code in it and paste it over the original image file code, delete the new SVG_... file. Any links to or semantics of the original file work as before. If it's an EPUB3, also use "Tools/Epub3 Tools/Update Manifest Properties" to add the SVG tag to the file in the manifest.
If there are any ID anchors in the original file, you can preserve them or adjust any links to them to just be to the file, not the anchor. Epubcheck will tell you if you need to do that.

If it's a cover image, as long as the original cover file was tagged as "Cover" (in the OPF), then the Sigil built-in "Add cover" will overwrite it, again preserving all links.

Possibly the SVG plugin could have an additional option allowing you to choose the target filename, either the default (new) one as now or an existing one to overwrite.

[Queen Fiona]

Originally Posted by enterpr1se

Is it normal the svg import image with a smaller width and hight?
I have a photo 1000px x 1511px
But the viewBox will become "0 0 260 400"
and the image size will become width="260" height="400"

	<svg 
	xmlns="http://www.w3.org/2000/svg"
	height="100%"  width="100%"
	preserveAspectRatio="xMidYMid meet" version="1.1"
	viewBox="0 0 400 264"
	xmlns:xlink="http://www.w3.org/1999/xlink">
	<image width="400" height="264" xlink:href="../Images/ffdl-0.jpg"/>
	</svg>

As seen here, I have this exact same issue. Why are the viewBox and image size tags so much smaller than the actual image? I did a quick scan of the code, and while I couldn't figure out why this is happening, the comments in the code suggest this behaviour is unintended.

[DiapDealer]

More than likely, the image's actual size is not being correctly retrieved by the PIL Python library. This would imply to me that there's probably something wrong with the original images in general. Is ffdl-0.jpg an actual jpg, or does it just have a .jpg extension? How was it created? Are other images' sizes being correctly determined by the plugin, or is it just some images?

Can you share an image that the plugin is "getting wrong?" That would probably be the most helpful thing for debugging purposes.

[Thomas_AR]

Same issue here with every image i inserted since i use this plugin.

Greetings from the cold Buenos Aires
Thomas