An issue in Preview

[KevinH]

I went ahead and pushed my "fix" to master but I really need a way to properly test it with your test epub.

Ideas anyone?

[philja]

Originally Posted by DNSB

For what it may be worth, I see what @philja is reporting. If I remove the url from the link to the filter, it shows a solid colour in Preview.

Yes, I confirm that.

Also, if you go into the file Metal_Filter.svg, and remove line 7, <feComposite ..., the image goes a dark gray.

And if you remove just line 13 <feComposite ... , the image goes a paler gray.

Each time, you need to change to another tab and back in CV to see the result.

But I never get any red. Strange that RbnJrg and Turtle91 get different results.

[KevinH]

@philja,
I am seeing exactly what you are seeing. Very strange.

[KevinH]

FWIW if I change Image1.svg fill style to 007777 I can see the result immediately in Preview with my latest push to master, so I think everything is working as I hoped.

I still have no idea why I can not see the red (or any color at all)

[DiapDealer]

For the record, I'm seeing three different things when opening the sample epub on my Arch System:

When I open it with the Sigil 2.6.0 AppImage (using Qt 6.8.2) I see no color at all.

When I open it with the repo supplied Sigil 2.6.0 (/usr/bin/sigil using the system Qt 6.9.1), I see it as pinkish colored.

When I open a custom built version of the latest Sigil codebase (again using the system Qt 6.9.1), I see dark, metallic red.

Either something is missing from the AppImage, or is different in Qt 6.9.1 from 6.8.2, or a little of both.

[RbnJrg]

Originally Posted by DNSB

For what it may be worth, I see what @philja is reporting. If I remove the url from the link to the filter, it shows a solid colour in Preview.

Noooo! If you remove the link to the filter you remove the filter

[RbnJrg]

Originally Posted by philja

Yes, I confirm that.

Also, if you go into the file Metal_Filter.svg, and remove line 7, <feComposite ..., the image goes a dark gray.

And if you remove just line 13 <feComposite ... , the image goes a paler gray.

Each time, you need to change to another tab and back in CV to see the result.

But I never get any red. Strange that RbnJrg and Turtle91 get different results.

Nooo. The filter is ok; if you remove any line of it, then you won't see any effect. As I said, the Image1.svg is just a plain, flat graycale image.

[RbnJrg]

Originally Posted by KevinH

FWIW if I change Image1.svg fill style to 007777 I can see the result immediately in Preview with my latest push to master, so I think everything is working as I hoped.

I still have no idea why I can not see the red (or any color at all)

You should change the color to 777777 that is a perfect grey. With 007777 you see a cyan color but no effect applied by the filter. If you instead of 777777 should write 333 you also would have see a "color" (in that case, a darker grey. that is not a color ). The best results given by the filter are achieved with a gray image (because of the overlay mode in the FeBlend primitive).

By the way, in my system, with #007777 I have the same behavior that with #777 (I have to change from .xhtml file to see changes in colors).

[RbnJrg]

Well, something weird is happening here. When I open the attached epub with Sigil 2.6.0 with Qt 6.9.1 (in my Arch Linux) I see what I posted in previous posts, that is, an image with an effect of red (or any color) brushed metal and 3D appearence. But when I open the same epub with the AppImage, I see what philja posted (no matter if Image1.svg has fill="#777" or fill="#777777"). There must be a bug in someplace.

[KevinH]

Differences between Qt 6.8.2 and Qt 6.9.1. The Appimage uses our internal Qt 6.8.2 version too, not the system Qt

[KevinH]

Yes, I can confirm this is a Qt issue. I tested your epub under Manjaro linux with Qt 6.9.1 with a Sigil I built myself, and I can now see the red metalic.

So The update to a later QtWebEngine in Qt 6.9.1 fixes the issue.

And I can now test my fix and it does NOT work when editing in the style svg but works when editing in the Image1.svg.

So something else is going on.

[philja]

Originally Posted by DiapDealer

Either something is missing from the AppImage, or is different in Qt 6.9.1 from 6.8.2, or a little of both.

I don't think it's the AppImage because I get the same gray results with Sigil 2.6.0 and its Qt 6.8.2in W11 and MacBook.

Looks like Qt has the answer.

Whoops - I missed Kevin's confirmation of Qt

[KevinH]

This is an interesting test case for a number of issues it illustrates:

1. SourceUpdates for CSS and HTML for did not look for or update CSS filter properties with urls (had to add the property filter to the list of properties who may have url values). To see this rename Metal_Filter.svg in BookBrowser and see it error.
I have pushed a fix for this to master.

2. GumboInterface did not update CSS urls with fragments properly.
Fragments on url() used in styles attributes are not commonly found or tested so that issue has never shown up before. This is part of the fix for the above issue as well. I have pushed a fix for this to master.

3. Qt 6.8.2 is broken for this type of svg filter. Qt 6.9.1 is needed to get this to work at all. Something we can not easily work around.

4. Something about that style attribute is internally cached by QtWebEngine and not even a proper full web cache flush after saving the changed Filter_Meta.svg will force it to update properly! It seems to *require* a new xhtml file to be loaded (in this case the nav) so that everything old about that style is forgotten and then the original xhtml file must be reloaded to see the change.

I can track down where the actual save to disk for that Filter_Meta.svg is done, so that is not the problem.

Unfortunately, this last one is not something I can easily workaround or fix.
It only happens with a style attribute with a url to an svg file element. Direct CV edits to Image1.svg are immediately and properly reloaded with the changes I have already pushed to master.

So this is a bit of a nasty piece of code that should help improve Sigil!


I will keep looking to see if there is way to bypass the webcache that will allow us to work around this issue as well.

[KevinH]

What is really really strange is that if you load the Inspector and watch the network traffic when the xhtml file is loaded, you *NEVER* see Metal_Filter.svg come up as a resource, just Image1.svg.

So the Metal_Filter is never loaded through the Inspector Interface and therefore can never be flushed with the cache.

This is just not something I can fix or workaround until I understand where and how this style attribute resource is actually loaded and used. Inspector is not helping here.

So Strange!

[DiapDealer]

It's probably not a very satisfying workaround, but this all seems to work (including in an AppImage built with Qt 6.8.2) if you simply embed the svg filter define (from Metal_Filter.svg) in the xhtml of Section0001.xhtml rather than defining it in a separate file. I included your latest changes to rebuild the AppImage.

Then it's simply a matter of changing the filter url from "url(../Images/Metal_Filter.svg#metal)" to simply url(#metal):

<p><img style="filter: url(#metal)" alt="Image1" src="../Images/Image1.svg"/></p>