Sigil not saving media as part of EPUB

[JackTrade]

I have an HTML file in one folder, incorporating media files which are in another folder.

When I open the HTML file with Sigil (or Firefox), everything works fine and the files (audio or images) show up where and as expected. However, when I save the file as an EPUB (or EPUB3), the resulting EPUB seems to include only the HTML part, and doesn't incorporate the media files. I can reopen it correctly in Sigil, but if I want to use a copy of the EPUB in, for example, my Android tablet, the media files are, obviously, missing.

There must be a simple solution to this, but my searches came up with nothing.

Thanks.

[Toxaris]

Usually when you import an HTML file into Sigil, it should also load the media files and adapt the links. The problem you have is that the media files are not in the ePUB. You need to import them as well and adapt the links.

How do you open the HTML file in Sigil?

[DiapDealer]

I can't duplicate this. When I open (or 'Add Existing') HTML files in the latest version of Sigil, all properly linked images (as well as css) get added to the resulting epub automatically.

NOTE: they have to be urls that contain src paths to the images that are relative to the html file in question (ex: src="../images/image001.jpg"). Images that use absolute file-path urls (ex: src="file:///C:/users/blah/desktop/image001.jpg") will not get imported into Sigil upon opening/importing (even though the image can be seen in the Preview Window). Perhaps that's what's going on? Those are recognized as external urls (like a link to an external website in an ebook) and are not processed/adjusted by Sigil.

The bottom line is: if you can't see the image file in the 'Images' folder of Sigil's Book Browser, then the image isn't a part of the epub (and won't be saved).

@KevinH: any way we could prevent Book View/Preview from displaying images that contain protocol prefixes (http://, or file:///)? It would be easier to know that something is wrong if these linked-in, external images didn't display. Or do they need to display for EPUB spec-compliance of some kind?

[JackTrade]

Originally Posted by DiapDealer

NOTE: they have to be urls that contain src paths to the images that are relative to the html file in question (ex: src="../images/image001.jpg"). Images that use absolute file-path urls (ex: src="file:///C:/users/blah/desktop/image001.jpg") will not get imported into Sigil upon opening/importing (even though the image can be seen in the Preview Window). Perhaps that's what's going on? Those are recognized as external urls (like a link to an external website in an ebook) and are not processed/adjusted by Sigil.

Yup, that was it - the src paths were absolute, not relative. I don't know why it's an issue, but importing those files into the Sigil folders and converting absolute to relative solved the problem.

Interesting to note - the html file contains a link to a CSS file which was originally located in the same folder as that html file. Sigil seems to have copied the CSS file into its "../Styles" folder and converted the path - all without human intervention...

[DiapDealer]

Originally Posted by JackTrade

Interesting to note - the html file contains a link to a CSS file which was originally located in the same folder as that html file. Sigil seems to have copied the CSS file into its "../Styles" folder and converted the path - all without human intervention...

Yes. That is by design. The same would have happened with your images files if they had originally been in the same folder as the html file. Sigil (for the time being) requires a strict internal structure for all of it's tools and features to work properly. So it moves files into the folders it needs them to be in and adjusts all links accordingly. It is hoped that this won't always be the case in the future, but for now it is just "how Sigil works."

[JackTrade]

Well, the mystery deepens...

I closed Sigil and later reopened the EPUB - all the media files are gone! The "../Images/" and "../Audio/" folders are empty.

Fortunately, I have these files in their original locations and can re-copy them to the respective folders - but is this happening???

[DiapDealer]

That's not really possible. If they were showing in the Book Browser when the EPUB was saved ... then the images were saved with the EPUB.

The only possible exception to this would be if you're using a Mac and you're in the habit of leaving EPUBs open in Sigil for more than 48 hours (and since your initial post was made way less than 48 hours ago ... I'm dismissing this scenario as highly improbable).

Make absolutely certain the EPUB you're saving is the EPUB you're re-opening. Also make sure you're not meddling with files in Sigil's scratch/temp directory while Sigil has the EPUB open.

[JackTrade]

Originally Posted by DiapDealer

That's not really possible. If they were showing in the Book Browser when the EPUB was saved ... then the images were saved with the EPUB.

The only possible exception to this would be if you're using a Mac and you're in the habit of leaving EPUBs open in Sigil for more than 48 hours (and since your initial post was made way less than 48 hours ago ... I'm dismissing this scenario as highly improbable).

Make absolutely certain the EPUB you're saving is the EPUB you're re-opening. Also make sure you're not meddling with files in Sigil's scratch/temp directory while Sigil has the EPUB open.

Well, the impossible is made manifestly possible

First, it's not a Mac - I'm on a Window 7 system.

Second, there's only one EPUB file in that folder, so I'm using the right EPUB.

Third, and most bizzare - I closed Sigil, went to the empty Audio and Images folders and re-pasted the missing files. I then left the Audio folder open in File Explorer and then, on another File Explorer window, clicked on the EPUB. Sigil opened up and a second later, all the files in the Audio folder were erased - right in front of my eyes! I checked, and the same thing happened in the Images folder.

It may (or may not) be helpful to note that in the C:\Users\user\AppData\Local\Temp folder there are several Sigil subfolders, two of which (Sigil-2aKwbE and Sigil-5tMg1p) with an identical Date Modified time stamp, plus 3 more files like that, time-stamped from earlier. All of these are empty (except for an empty OEBPS folder).

[DiapDealer]

Originally Posted by JackTrade

Third, and most bizzare - I closed Sigil, went to the empty Audio and Images folders and re-pasted the missing files. I then left the Audio folder open in File Explorer and then, on another File Explorer window, clicked on the EPUB. Sigil opened up and a second later, all the files in the Audio folder were erased - right in front of my eyes! I checked, and the same thing happened in the Images folder.

I'm not following at all. If you've closed Sigil, then you have no Audio and Images folders to go to with File Explorer (unless you're messing with Sigil's temp folders--which you've assured me you're not). An EPUB is a zip archive and you don't have access to its files and folders, once it's created, unless you unzip it (or use archiving software to access them--which is essentially the same thing).

Originally Posted by JackTrade

It may (or may not) be helpful to note that in the C:\Users\user\AppData\Local\Temp folder there are several Sigil subfolders, two of which (Sigil-2aKwbE and Sigil-5tMg1p) with an identical Date Modified time stamp, plus 3 more files like that, time-stamped from earlier. All of these are empty (except for an empty OEBPS folder).

It IS helpful, but probably not in the way you might imagine. This is exacly what I meant when I said you should not be messing with Sigil's temp folders/files when Sigil has them open, or is attempting to open them.

I think you may be confusing the self-contained *.epub archive with the original files/folders you created it from. Either that, or you're pasting image files into Sigil's temp working directories via File Explorer (with Sigil open, or opening), which you definitely should not be doing. The only thing you can do in "C:\Users\user\AppData\Local\Temp" with regard to Sigil is break things. It really should be considered a complete no-fly zone (with possibly the exception of trying to recover some data after a crash) for users.

[BetterRed]

Originally Posted by DiapDealer

[. . .] Sigil (for the time being) requires a strict internal structure for all of it's tools and features to work properly. It is hoped that this won't always be the case in the future, but for now it is just "how Sigil works."

Hmmm, I quite like the fact that Sigil segregates files of different kind into separate folders. On occasions I open and save an epub in Sigil for the express purpose of getting the different subfolders when I unzip the epub.

Why do I do that, editing an audio or video file can take a considerable amount of time, and I am uncomfortable running my media editing tools as subtasks of Sigil.

Its one of the reasons I use Sigil as my primary ePub editor.

BR

[DiapDealer]

Originally Posted by BetterRed

Hmmm, I quite like the fact that Sigil segregates files of different kind into separate folders. On occasions I open and save an epub in Sigil for the express purpose of getting the different subfolders when I unzip the epub.

Why do I do that, editing an audio or video file can take a considerable amount of time, and I am uncomfortable running my media editing tools as subtasks of Sigil.

Its one of the reasons I use Sigil as my primary ePub editor.

BR

I rather like it myself, too. And I can't imagine not always including some sort of easy/quick feature to achieve it. But being able to define/maintain their own internal structure has long been on users' wishlists.

There's been no real work on that front, but it is on the long-term to-do list.

[BetterRed]

Originally Posted by DiapDealer

I rather like it myself, too. And I can't imagine not always including some sort of easy/quick feature to achieve it. But being able to define/maintain their own internal structure has long been on users' wishlists.

There's been no real work on that front, but it is on the long-term to-do list.

Thanks, if the structure is user configurable that'll be fine, suggest default structure be close as possible to what it is now

I was worried you going along the path of flattening what's there and having 'virtual' folders in the Book Browser, I'm of the old-school actual real world kind

ETA : the ability to gather files into chapter folders might also be useful (body text, images, notes etc).

BR

[JackTrade]

Originally Posted by DiapDealer

An EPUB is a zip archive and you don't have access to its files and folders, once it's created, unless you unzip it (or use archiving software to access them--which is essentially the same thing).
.......The only thing you can do in "C:\Users\user\AppData\Local\Temp" with regard to Sigil is break things. It really should be considered a complete no-fly zone (with possibly the exception of trying to recover some data after a crash) for users.

In that case, given the fact that the media files are apparently not present in the archive, what is the best way to re-introduce them? I imagine I can go to to the each media link in the html file, press Ctrl-Shift-i and reimport the media file from it's original location. But the html file contains links to dozens of media files and that's a lot of work.

Is there another way?

[DiapDealer]

Two ways that come to mind:

1) Use regex to change all of the absolute paths in the original html to relative paths, import the html and images into Sigil in one go (Add Existing) ... save the epub.

2) Add the original html to Sigil. Add all of the original images to Sigil. Use regex to modify all the absolute paths in the html to the relative path that Sigil expects ...save the epub.

Can I ask why the image links in the html use absolute file:/// urls for the src attributes in the first place? It's not a very common practice. Relative paths make everything very portable and easily/quickly relocatable.

[JackTrade]

Originally Posted by DiapDealer

Can I ask why the image links in the html use absolute file:/// urls for the src attributes in the first place? It's not a very common practice. Relative paths make everything very portable and easily/quickly relocatable.

Well, that's a pretty long story, but - at the risk of boring you - I'll tell it, since it may help others as well.

Fundamentally, what I'm trying to produce is an ebook about music: it consists of text plus short snippets of audio (mp3s) and related small sheet music images (jpgs/pngs). For various design reasons, these audio and image pieces are presented in a popup box triggered by a highlighted link in the text. If the reader decides to click on the link, the windows pops up, displaying the audio player and related sheet music snippet; once he's done, the reader clicks the Close button in the corner of the popup box and is returned to the text. The ebook contains numerous links like that and consists of several chapters.

As you can imagine, this type of project involves a lot of html/css hacking; unfortunately, Sigil isn't the ideal platform for that and I have had to struggle with it over the last few weeks. At some point I decided it would be a good idea to try to develop the project as a website, using CoffeeCup as the html editor, see if that makes it easier to get the design work done and then import it into Sigil and let Sigil turn it into an epub.

As an experiment, I copied into a CoffeeCup folder the html of part of one chapter and its related css file, with about a dozen popup boxes. I opened it in CoffeeCup; it opened fine, but I had to convert the Sigil relative src="../ addresses of the media files to their absolute address in the original (non-Sigil) folder where they reside. Everything went smoothly. The sample chapter opened in Firefox with all the text, the popup boxes and the popup content without a hitch.

At that point I figured it's time to convert the sample chapter into an epub. Back to Sigil I went - I opened the HTML page in Sigil; I don't know if that, in and of itself, caused some or all the problems - but I didn't (like you suggested) use Add Exiting, just plain Open, navigated to the folder where the HTML page was located, changed the Sigil default Open mask from .epub to .html and loaded the page. As I mentioned in a previous message, the page and its related css loaded perfectly, but the media files did not. As you suggested, I converted the absolute addresses to relative addresses in the Sigil html file and everything was fine and behaved exactly as expected. I saved it as an epub3 file.

Now the fun and games started - I tried opening that epub with the Firefox epub reader extension; it wouldn't open (this may be an issue with the extension, not the epub). I tried to open it with Adobe Digital Editions; the book opened with all the links highlighted in the right places, but the popup boxes just didn't pop up.

Finally, I copied the epub to my android tablet. None of the supposed android epub3 readers would even open the file, except for one: Gitden Reader. When it opened, the text itself and highlighted links were fine. However, clicking on the links resulted in one of the flowing outcomes:

1. Nothing happens.
2. A blank popup box pops up.
3. A popup box with an image but not the related audio.
4. A popup box with a blank audio player (with or without the related image), but no related audio.

And, finally, for a small percentage of the links:
5. The intended result: a popup box containing both an image and an audio snippet that could actually be played and closed properly.

So, in my infinite wisdom, I decided to go back to Sigil to see what went wrong in the process of converting a working html/css file to an epub. And that was when I discovered, upon re-opening the epub in Sigil, that the text was fine, but that all the media files were gone - so each popup box did popup, but it contained only two of those Xs indicating the referenced file is missing.

And that's how I got to where we are today. This is probably far more than you wanted to know but, as I said, it may help someone else avoid the same issues...