Plugin to insert and wrap an image with SVG

[KevinH]

Okay tried this with Manjaro. Could Copy with no problems but the selected image never showed up in the right side pane for some reason. Tk can be a bit flakey at times.

Update: It seems only .png files will not show but jpg files will properly show. This is true on macOS as well.

Also this plugin requires an epub that has been "Restructured to Sigil norm" to work as the link it provided was just way wrong otherwise. Once I did that, all seemed to work.

[DiapDealer]

I discovered what was going wrong on Arch (and probably Manjaro as well):

When resizing/thumbnailing the images in the epub using Pillow's Image class, the plugin is using the Image.ANTIALIAS constant as a parameter. And that is what is silently failing on Archlinux. That's why no images show up when selecting them.

From what I can tell, all Pillow resizing methods have been Antialiased since Pillow 2.7.0. At that same time, ANTIALIAS was renamed to LANCZOS. The ANTIALIAS constant was left in for backward compatibility. So it's not necessary to use it.

Pillow has finally gotten around to removing the deprecated ANTIALIAS constant in Pillow v10, and that's the version of the python-pillow package in Arch's repositories. The version of Pillow included with the latest Windows and macOS versions of Sigil is Pillow 9.5.0.

So the bottom line is that the first version of Pillow included with Sigil was long, long, loooong after ANTIALIAS became unnecessary (Pillow 2.7.0). Remove it in the two places in the plugin and nothing will change (except that the plugin will work with newer versions of Pillow).

[KevinH]

Yes removing ANTIALIAS in those two places worked like a charm in Manjaro now that xclip and xsel are installed. png showed nicely as well.

On macOS, I was testing with the alice in wonderland test epub and forgot the 4 of the 5 png images where **transparent** spacer images!

Once I selected a png with an actual image in it, everything worked.

Thanks!

[CalibUser]

@ DiapDealer: Thanks for tracking down this issue. I have put an updated version of the plugin in the first post in this thread.

[DiapDealer]

No problem. More here on Pillow's 10.0 deprecation removals: https://pillow.readthedocs.io/en/sta...es/10.0.0.html

[philja]

Just found today that the plugin has been updated to v0.2.1.4 so I installed that to check. There was one surprise, though. It still registers in Sigil as 0.2.1.3

When I look inside its plugin.xml file, line 8 still shows:
<version>0.2.1.3</version>

In any case, whatever mod the developer made does not make the 'Copy' function load an image to the clipboard on my linux box.

I've found the two replacements of ANTIALIAS in 0.2.1.3 lines 329, 351 by LANCZOS. It hasn't helped my flatpak installtion.

[KevinH]

Works with Manjaro (after adding xsel and xclip). And works with Arch. Did you ever run the terminal test I posted earlier to prove if xsel -ib worked to load the word "hello" onto the clipboard? Did it work?

[DiapDealer]

Quick question: If phijla is using a Flatpak version of Sigil, can that not introduce sandbox issues? Could the problem be that Flatpak itself does not make xsel and xclip available to its apps (even if available on the host machine)?

From what I understand, you can use the following command to see what commands are available to Flatpak Sigil with the following command:

flatpak enter com.sigil_ebook.Sigil /bin/bash

if you don't see xsel/xclip in the output, it might be necessary for the Flatpak Sigil maintainer to include them. They've made such changes in the past to accommodate third-party plugin needs, I think.

[philja]

Originally Posted by KevinH

Works with Manjaro (after adding xsel and xclip). And works with Arch. Did you ever run the terminal test I posted earlier to prove if xsel -ib worked to load the word "hello" onto the clipboard? Did it work?

Yes, I did note in my reply above that I had installed xclip and carried out your 'hello' test and it did get written to the clipboard.

In W10, the plugin gives me a message each time that an image has been copied to the clipboard. In my linux box, the plugin does not give this message so I presume the plugin has not carried out the copy procedure.

[philja]

Originally Posted by DiapDealer

Quick question: If phijla is using a Flatpak version of Sigil, can that not introduce sandbox issues? Could the problem be that Flatpak itself does not make xsel and xclip available to its apps (even if available on the host machine)?

From what I understand, you can use the following command to see what commands are available to Flatpak Sigil with the following command:

flatpak enter com.sigil_ebook.Sigil /bin/bash

if you don't see xsel/xclip in the output, it might be necessary for the Flatpak Sigil maintainer to include them. They've made such changes in the past to accommodate third-party plugin needs, I think.

I agree that could be a possibility. When I first made the flatpak installation it could not find my java runtime. I noted in another thread somewhere that I mentioned the lack of this dependency to the devs of the flatpak version and it was remedied overnight.

Re your bit of code, I copied and ran it in a terminal and it did nothing. I suppose you intended it to be run in a terminal - but where?

[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:

<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:

<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

<image width="724" height="721" xlink:href="../Images/images/image021.gif"/>

whereas it was originally :

<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.

And the solution seems to be to 'restructure to Sigil Norm'.

[KevinH]

The problem is sandboxing an app like Sigil that uses PageEdit as an external editor, that uses OpenWith to open lots of third party editing tools chosen by the user including gimp, svg editors, etc, etc, and third party python plugins that can run lots of OS commands and tools (including java) just makes no sense at all. The flatpak version is quite handicapped and limited.

The right way to effectively "sandbox" an app like Sigil is to run it in a VM with a full set of other tools that can be employed with Sigil (like PageEdit, gimp java, etc etc) to make a VM playground tool).

Have you thought about running a Manjaro VM (or some other linux VM that properly updates things like Sigil) on your linux box and not running flatpak?

[KevinH]

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.

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:

<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:

<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

<image width="724" height="721" xlink:href="../Images/images/image021.gif"/>

whereas it was originally :

<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.

[DiapDealer]

Originally Posted by philja

When I first made the flatpak installation it could not find my java runtime. I noted in another thread somewhere that I mentioned the lack of this dependency to the devs of the flatpak version and it was remedied overnight.

Yours is the issue I was thinking of then.

Originally Posted by philja

Re your bit of code, I copied and ran it in a terminal and it did nothing. I suppose you intended it to be run in a terminal - but where?

I'm not entirely certain. I copied it from another similar tech support issue I found online. I'm not that Flatpak fluent. It's definitely meant to be run from a command line, though. I understand that it may need to be run as root, though.

So maybe first try:

sudo flatpak enter com.sigil_ebook.Sigil /bin/bash

or if the above does nothing, maybe try:

sudo -E flatpak enter com.sigil_ebook.Sigil /bin/bash

It's also possible they may need to be run while the Sigil Flatpak is running.

[philja]

Originally Posted by DiapDealer

Yours is the issue I was thinking of then.

I'm not entirely certain. I copied it from another similar tech support issue I found online. I'm not that Flatpak fluent. It's definitely meant to be run from a command line, though. I understand that it may need to be run as root, though.

So maybe first try:

sudo flatpak enter com.sigil_ebook.Sigil /bin/bash

or if the above does nothing, maybe try:

sudo -E flatpak enter com.sigil_ebook.Sigil /bin/bash

It's also possible they may need to be run while the Sigil Flatpak is running.

There's certainly a small difference whether the flatpak Sigil is running or not. I ran the code snippets from my prompt in my home directory. If Sigil is not running, all versions of your code (with or without sudo) return this error :

error: com.sigil_ebook.Sigil is neither a pid nor an application or instance ID

If Sigil is running, they append my home directory to my prompt and leave me with some process running. It needs 'exit' to return to the normal prompt.

I've been to the flathub website. Last time I when I had the inability to find java, it was really easy to find somewhere to place a query. This time, I can't find any reference to Sigil and I'll have to open an account. I'll leave that to tomorrow.