image url looking in temp folder for file

[david_f1]

Hi,

I'm modifying the CSS file of an epub I've created to have a background image:

h1:before {
    background-image: url('../01-roman-devon/gold-aureus.jpg');
    display: block;
}

However, the image doesn't show up in the epub. When looking at the inspector it's trying to look in a subfolder of the Sigil temp folder, and then appending the URL above to it (including the dots)

This is on Sigil 0.9.6 on Windows. Can anyone help?

Thanks

[theducks]

you are using Sigil
Sigil flattens and sectionalizes by file function

"../Images/gold-aureus.jpg"

[eschwartz]

Originally Posted by theducks

you are using Sigil
Sigil flattens and sectionalizes by file function

"../Images/gold-aureus.jpg"

And, critically, Sigil does not know how to auto-correct url() links in CSS, which it normally does for the HTML links in the rest of the book.

[DiapDealer]

Originally Posted by eschwartz

And, critically, Sigil does not know how to auto-correct url() links in CSS, which it normally does for the HTML links in the rest of the book.

Sure it does. You must have "Mend on Open" enabled, of course. It works for me anyway. I just tested it on an epub I created that used a "pictures" folder instead of "Images." I even added a background image via a css url() link like the one in question that pointed to an image in that "pictures" folder.

When I opened the epub in Sigil for the first time, all links were properly updated (including the css url() link) to reflect the required "Images" folder. When I rename the image file in the Book Browser, the url() link in the css file is also updated to reflect the change.

This is all predicated, of course, on the image(s) being properly manifested in the opf in the first place. If the href in the manifest is incorrect, Sigil can't update the links properly when "normalizing" an epub upon opening -- which is what I'm guessing happened to the OP in the first place, and why the url() link wasn't properly updated. Either that or they really manually typed an url link that cannot exist in Sigil using Sigil. Sigil can't fix what Sigil don't know.

If you want to manually create an url() link to an image file in a css file using Sigil, then it simply HAS to start with '../Images'. Nothing else will work.

Adding url('../01-roman-devon/gold-aureus.jpg') to a css file within Sigil is going to result in broken link every single time. Plain and simple. And nothing is ever going to automatically fix it because there's no matching image in the OPF manifest. There can't be in a Sigil epub.

[KevinH]

Yes as DiapDealer said it will fix url links in the css just fine assuming the url was correct upon import.

[eschwartz]

Huh. Well then.

Perhaps I misremembered something (or remembered an old something).

[DiapDealer]

Originally Posted by eschwartz

Huh. Well then.

Perhaps I misremembered something (or remembered an old something).

Quite possibly an "old something." Because I felt compelled to test just to be certain before I said anything, if I'm totally honest.

[DNSB]

Hmmm.... a couple of items I've noted is that when an epub has images in an images directory, Sigil will rename the directory to Images but not correct the case in the link so the link is ../images/image.jpg which needs to be corrected to ../Images/image.jpg. If stylesheets are moved to a Sigil created Styles subdirectory from the OEBPS (or equivalent) directory, the links are left pointing to ../stylesheetname.css instead of ../Styles/stylesheetname.css.

The type of epub where any resemblance to the epub standards is purely coincidental.

[DiapDealer]

Originally Posted by DNSB

Hmmm.... a couple of items I've noted is that when an epub has images in an images directory, Sigil will rename the directory to Images but not correct the case in the link so the link is ../images/image.jpg which needs to be corrected to ../Images/image.jpg. If stylesheets are moved to a Sigil created Styles subdirectory from the OEBPS (or equivalent) directory, the links are left pointing to ../stylesheetname.css instead of ../Styles/stylesheetname.css.

The type of epub where any resemblance to the epub standards is purely coincidental.

As I mentioned above, the only time I see that happen is if the files were not properly manifested in the opf in the first place. If the relative href in the manifest is not correct to begin with (case sensitively correct), links won't be properly updated when opening such an epub with Sigil. That applies to text, images or stylesheets.

The same can happen if errors are encountered when opening an epub and you decline to let Sigil automatically fix them. Garbage in, garbage out.

If you can share non-copyrighted examples of well-formed epubs with properly manifested files whose links aren't properly updated when opened in Sigil, we'll certainly do our best to track the problem down.

[Doitsu]

@DiapDealer:
I wasn't able to reproduce the OP's issue either, but found out that Sigil doesn't properly resolve stylesheet image references if an epub contains two images with the same file name in different subfolders.

For example, my (valid) test epub contains two different versions of blue.jpg in different subfolders. After opening with Sigil, the second version of blue.jpg was renamed to blue0001.jpg, but the CSS file reference wasn't updated.

Before:

#blue_one {
background-image: url('../images/blueone/blue.jpg');
}

#blue_two {
background-image: url('../images/bluetwo/blue.jpg');
}

After:

#blue_one {
background-image: url('../Images/blue.jpg');
}

#blue_two {
background-image: url('../Images/blue.jpg');
}

I realize that the end user is highly unlikely to encounter such a poorly designed epub in real life, but, IMHO, it couldn't hurt to check for this.

[DiapDealer]

@Doitsu:

It's not just image references in stylesheets that suffer from that problem. Any img hrefs that exist in the (x)html are not updated properly either (under those same conditions).

Actually, I appear to have messed up the case of the href links in my test.

Sigil's normalization process handles the dupe basename situation fine with regard to img hrefs in the xhtml. It still doesn't handle the url() links in css properly, though, with duplicate basenames.

Strange, but very "fringe use" like you mentioned. We'll look into it though.

[KevinH]

Yes, xhtml updates use a full parser (gumbo) but the css updates use regular expressions and the key for the regular expression replacement is the original filename not the original full file path. This is hopefully the last hold-over from the old Sigil code-base that had a problem with similarly named files in different directories. I thought I had fixed them all. We will track this down and fix it too.

[KevinH]

A fix for this has been just now pushed to master. It still needs some testing to make sure I did not mess anything up but appears to work with the posted normalization.epub test case.

[DiapDealer]

Thanks, Kevin. I'll try to take a peek this afternoon/eve.

[DNSB]

Originally Posted by DiapDealer

The same can happen if errors are encountered when opening an epub and you decline to let Sigil automatically fix them. Garbage in, garbage out.

If you can share non-copyrighted examples of well-formed epubs with properly manifested files whose links aren't properly updated when opened in Sigil, we'll certainly do our best to track the problem down.

I haven't found this issue with well-formed epubs. This is an issue I see with epubs that are not well-formed often created with older software -- the type of epub that I use Sigil to drag into compliance.