Plugin to insert and wrap an image with SVG

[philja]

Originally Posted by Doitsu

Try changing the code in plugin.py as follows:....
If that doesn't work either, try the attached pyperclip-based test plugin.

I changed the code in CCTest plugin's plugin.py, loaded the revised CCTest plugin and ran it. Sadly, the result was the same:

QT: session management error: could not open network socket
Status: success
Done.

I installed and ran the PCTest plugin. Result was :

QSettings::value: Empty key passed
QSettings::value: Empty key passed
Qt: session management error: could not open network socket
Status: success
Done.

Nothing was copied to my system clipboard and nothing was able to be pasted into Sigil by either test.
Thanks for trying.

[philja]

I posted to the Flathub Sigil page about this problem with the inability to access xsel and xclip on September 17. There has been no interest or response on that site. In addition, I get occasional episodes where my Flatpak version of Sigil freezes with the Preview pane greyed out with a message 'Loading'. This never recovers.

Today I've been unable to open and explore a curious ePub originating from a conversion on Google Docs. It never opens sufficiently to allow me explore its curious style entries - always displaying the 'Loading' message in the Preview pane.

So I'm going to try to call it a day with the Flatpak version and attempt to build Sigil myself following the detailed explanation on :
https://github.com/Sigil-Ebook/Sigil...Linux.md#sigil

[DiapDealer]

The latest Sigil source will default to building with Qt6. I would recommend doing so if your distro can provide the minimum requirements for doing so. https://github.com/Sigil-Ebook/Sigil...ux_with_Qt6.md

If not, you'll need to add -DUSE_QT5=1 to the original cmake configuration in the instructions you'll be using.

This change is explained in the Building on Linux section of the main README: https://github.com/Sigil-Ebook/Sigil...ld-and-install

Conversation continued here.

[philja]

Having given up on the Flatpak version of Sigil and then getting Sigil 2.0.2 to work fine on UbuntuStudio 22.04.3 using Qt6, I decided to have another go with the InsertImageSVG plugin. It worked pretty well as expected but I did have a couple of problems: one with the UserGuide and another with images in an eBook which failed to display in the plugin's dialog box.

The ePub2 I used for the trial has one jpg image, the cover image, and 89 gif line drawings. The cover jpg displayed ok but when I clicked on the next gif in the images list, all I got was a blank, black display. Same with the next few gifs.

My first thought was that there was a problem with gifs but for a reason that I cannot explain, I went to the last gif in the list, 089.gif, and it displayed ok. I finally determined that 001.gif through 073.gif do not display in the plugin's dialog but 074.gif through 089.gif do display correctly.

I found that the plugin works correctly, inserting new xhtml files or copying an image into an existing xhtml file regardless of whether or not the image selected displays in the plugin's dialog. So the problem is one of display within the plugin.

I cannot see why the first 73 gifs do not display. All the gifs are of size between 6 and 8 KiB except the last one, 089.gif which is 100KiB. Could it be a memory allocation problem with the plugin? But why do the higher-numbered images display and not the lower numbered images?

The UserGuide: the UserGuide for this plugin has an image which does not display correctly. It has been named SVGImageDialog.JPG but the xhtml reference which calls this image to be displayed is shown on line 118 in UsingPlugin.xhtm as ;
<p><img alt="SVGImageDialog" src="../Images/SVGImageDialog.jpg"/></p>

JPG upper case in the image name and lower case in the xhtml file.

Sigil wouldn't allow me to rename the file in the images folder to SVGImageDialog.jpg saying that there was already a file of that name. So my solution was just to edit the entry on line 118 in UsingPlugin.xhtml to
<p><img alt="SVGImageDialog" src="../Images/SVGImageDialog.JPG"/></p>

Apparently, Sigil considers a file name with upper case JPG to be same as with lower case jpg so won't allow the name change. But the xhtml treats the cases differently.

[KevinH]

In Sigil, you need to do that file name change in 2 steps. First to some other name (i use temp or anything else you want that is not a case insensitive match) and then to the CaseSensitive variant name you wanted.

FYI,

Many epub2 devs used blank spacer image gifs (and lots of them) to make whitespace changes that really could have been done more properly with css. Some scanners even created them.

Perhaps you found one of those? Try opening that image directly in an Image Tab, or external browser to verify if truly blank (ie. a spacer image).

[CalibUser]

This issue did not occur on my computer (Windows 64). However, I have updated the image file in the guide in the first post of this thread, changing JPG to jpg, to fix the issue raised by philja.

[philja]

Originally Posted by KevinH

Many epub2 devs used blank spacer image gifs (and lots of them) to make whitespace changes that really could have been done more properly with css. Some scanners even created them.

Perhaps you found one of those? Try opening that image directly in an Image Tab, or external browser to verify if truly blank (ie. a spacer image).

I think you're talking about the first 73 gifs which did not display in the plugins window (because the other case-sensitive issue was resolved and the image then displayed as it should)?

It was one of my own books I was using and I know all those images by heart. They were all created in Inkscape and exported as pngs and then converted to gifs to lighten the load because they're all line drawings. They all display correctly in the epub in Sigil and all other e-reading devices I've tried.

It was only in the plugin's window that those images did not display but despite that, they were correctly used by the plugin to do its job.

And yes - if I need more white space, I use CSS and never a dummy image.

[KevinH]

So probably a bug in the PIL / Tk python modules of some sort.

Perhaps the bug resolved by DiapDealer in post 152 in this thread.

[philja]

Originally Posted by KevinH

So probably a bug in the PIL / Tk python modules of some sort.

Perhaps the bug resolved by DiapDealer in post 152 in this thread.

I'm using the latest version of the plugin, 02.1.4. I've checked in the plugin's plugin.py file to be sure and the two instances quoted by DiapDealer have

img_temp.thumbnail(size, Image.LANCZOS)

and not ANTIALIAS.

I've also tried several other epubs of my other books which have loads of gif files and the results are strange. In one book, the plugin displays all the gif thumbnails and in another book, it displays some and not others. The ones which are displayed are intermixed with the others and not first half/second half as in the first book I tried.

All the gifs in all the books have been prepared in the same way and are roughly the same size (of the order of 6-8KiB). I can't spot any common factor for those which do not display.

[KevinH]

Some gif files use different compression settings (not lzw to get around license concerns) and my guess is some software can not properly decompress some gif formats.

Maybe run a gif test/validation program to see what it says?

Some early gifs with transparent layers also give some software fits.

This is why png has almost completely replaced gifs (as gifs used to require a proprietary license and was patent restricted).

[KevinH]

I did an internet search on this and blank images in python/tk are usually caused by the image data itself being garbage collected by python. The way to prevent garbage collection of an image object is to keep a pointer to the image around until after the image is displayed/used.

Perhaps that is what is at play here?

In AccessAide which made thumbnail images, I needed to keep a pointer to both the full image and its thumbnail version to prevent both from being destroyed by garbage collection. They were linked. See the code starting here: https://github.com/kevinhendricks/Ac...cessgui.py#L98


In this plugin's code, I see copy() being used on Image objects but I am not sure that will keep a pointer to the original Image data and the thumbnail version.

That might be worth looking into.

[philja]

Originally Posted by KevinH

Some gif files use different compression settings (not lzw to get around license concerns) and my guess is some software can not properly decompress some gif formats.

All my images were designed in InkScape, exported as pngs and bulk converted to gifs using ImageMagick's mogrify command.

Maybe run a gif test/validation program to see what it says?

Do you have a suggestion for a program?

Some early gifs with transparent layers also give some software fits.

I didn't flatten the images because I wanted to retain transparency for the sake of those e-readers who use a colored page background (like I do). That avoids each image being apparently on a white background against, say, a pale green page. I know Amazon screws around with images so that's tough on their clients.

This is why png has almost completely replaced gifs (as gifs used to require a proprietary license and was patent restricted).

I was there when gifs were proprietary but now they're not. I converted to gifs because all the images are black and white line drawings and the gif version is about 20% of the size of the png.

[KevinH]

So that just leaves the image buffers being garbage collected by python before they are used.

I will take a look at the plugin code and run some tests. Can you pm me a link to your epub so I can test with it? Or point me to a public epub that shows similar issues in your machine?

I will then modify the code to keep the proper image pointers and replace the use of image copy() to see if that helps.

[philja]

Originally Posted by KevinH

So that just leaves the image buffers being garbage collected by python before they are used.

I will take a look at the plugin code and run some tests. Can you pm me a link to your epub so I can test with it? Or point me to a public epub that shows similar issues in your machine?

I will then modify the code to keep the proper image pointers and replace the use of image copy() to see if that helps.

I'm afraid the problem has become a little different. I was just making you a link to my book epub file which had the gif display problems with this plugin when I decided to have a quick recheck. Every gif now displays perfectly as a small image in the plugin window.

I went through all the other epub files where I previously found some gifs displayed and some didn't. Now they all display and I cannot find one that doesn't.

The only thing I've changed today is to download DiapDealer's AppImage : see
https://www.mobileread.com/forums/sh...12#post4373712

This AppImage is intended to provide all the bits and pieces for Qt6 operation in linux and avoids having to edit the wrapper file in /usr/local/bin/sigil to remove the QTLIB_DIR statement.

So with DiapDealer's AppImage in use, all the gifs now display.

To double-check, I changed the path in Sigil's plugin manager to use the system python and made sure the QTLIB_DIR statement was removed from the wrapper script. So I went back to the state where I had the gif display problems. And they're there again exactly as before: 001.gif - 073.gif will not display, 074.gif to 089.gif do display.

Going back to DiapDealer's AppImage again and all gifs display ok. It seems to be systematically repeatable.

In both cases, with AppImage and without, my Sigil 2.0.2 with Qt6 installation runs the testplugin with complete success.

That AppImage file must contain/provide something I was missing or which was deficient/corrupt in the installation work of Qt6 bits and pieces in that above-mentioned thread. But why only some gifs were affected remains a mystery.

Or something which is more tolerant of some deficiency in the plugin's code?

I don't know how useful it will be to pursue further down this rabbit hole.

[Turtle91]

It may be a more general Sigil problem rather than just this plug-in. I’ve been having some display issues with images … I just haven’t tracked it down to a repeatable set of steps. I do know that switching tabs and forcing a re-load causes the image to display correctly.

Most of my images are jpg/png, full page, wrapped in SVG. I haven’t noticed it on other images yet.

Thought I’d throw out this datapoint in case it helps.