Where is the image location alias found in epubs?

[philja]

I have three epub2 's to edit where the owner wants to improve the alt=" " for the images, amongst other changes.

The first thing I noticed was the way the images were coded in the xhtml files:

<img class="x65" src="Pictures/image1.gif" alt=" "/>

The images all appear conventionally in a folder named 'Images' in the Book Browser, and usually I find images in Code View like this:

<img class="x65" src="../Images/image1.gif" alt=" "/>

In the other two epubs, instead of 'Pictures', the images have src="images/image1.gif"

When I open most epubs in an archive viewer, there is the usual structure of a META-INF folder, an OEBPS folder, and a mimetype file. Inside the OEBPS folder, we find the Images, Text, Styles ... folders + the content.opf and ncx files.

When I examine these three epubs the same way, there is the META-INF folder, a Pictures (or images) folder (containing all the images), and all the text files are at the same level as the mimetype and content.opf file. There is no OEBPS folder.

They all pass the F7 and epubcheck tests ok.

I'm just curious - the images all display ok. Are these epubs the product of a particular conversion application?

[DiapDealer]

There is no specification for how epubs need to be structured. As long as the paths/links are valid, things will still work. Some applications have been known to create a completely flat epub structure. Some create other structures. Sigil USED to force its proprietary structure on every epub it opened/saved, but it hasn't done that for a long time. Many people became used to that structure.

The "Restructure to Sigil Norm" tool will restructure the epubs to the folder hierarchy many expect, but it's not at all required.

[DNSB]

I still use the Restructure tool but that is due to having gotten used to finding images in Images, etc. Old dogs and an adversion to new tricks.

Actually, there are a few rules for ePub structure. The mimetype file is required, must be in the root of the container and must be stored uncompressed. The container.xml file is required and must be stored in a META-INF directory in the root of the container. There are several other optional xml files (encryption.xml (required if obfuscation/encryption is used), manifest.xml, metadata.xml, rights.xml & signatures.xml). You will also commonly find that Apple and Kobo xml files are stored in the META-INF file though this is not required (com.apple.ibooks.display-options.xml & com.kobobooks.display-options.xml) and can cause an error message if they are also listed in the .opf file.

[DiapDealer]

Yes. You are correct. I didn't want to get into the particulars about the mimetype and the container.xml. they didn't seem relevant to @philja's question(s). There are no requirements for where the xhtml, css and image files (and even the opf file, so long as the path to it in the container.xml is correct) must live.

[philja]

Thankyou DiapDealer. I've never used the restructure tool before.

I made a checkpoint for security and then used the restructure to Sigil norms and it seems to have worked fine.

Like DNSB, I like conformity with what I'm familiar with - and it helps some of the regex work 'as is' without needing to revamp them.

Learning everyday

[Turtle91]

I always restructure to Sigil norms for the same reason… except when I forget to… that always causes me issues. I wonder if there is a way to add that as a preferences selection - to auto restructure on open or something???

[jugaor]

Originally Posted by Turtle91

I always restructure to Sigil norms for the same reason… except when I forget to… that always causes me issues. I wonder if there is a way to add that as a preferences selection - to auto restructure on open or something???

I'm in the same boat.
I support this idea, either as a new preference or an option in the ini file.

[KevinH]

No. We forced that for years but it violated the epub3 spec and will silently break any javascript, and break non-well formed code, etc. So just add it to an Automate List if you still use it frequently.

And fwiw, there is/was nothing special about Sigil's old forced folder structure. And you can use Sigil's tools to create any epub structure if you so desire. But forcing (even optionally) on first load a fixed structure is against spec and as I said can break things and so is a non-starter.

[Turtle91]

No worries.

Just wondering though - how can restructuring “break things”? Do I need to worry about running the restructure??

[KevinH]

Restructuring can break javascripts because they often assume paths to specific resources they interact with, but Sigil can not walk all javascript code to try to update it any more than they could for any other programming language.

Restructuring to Sigil norms, changes every file's path and therefore changes every relative link and path between them requiring walking every source updating any link or src or href or alt img src, font source in css, etc. So if some links just happen to work on Windows due to case folding, or are broken initially these can never be updated. Also file name collisions may happen from identically named images being moved to sit in the same folder (often an issue with compendium epubs). We try to detect and fix these cases but. I personally would never run it on any not-well formed epub that I had not checked the links first with Reports or epubcheck or ... and never if javascript is present in the original epub.

[KevinH]

That said, it is safe to use if all links, hrefs, src, css links, etc are correct and no javascript is used. I still first run epubcheck to help detect any broken links and fix them first, then Restructure to Sigil norm if needed. So its safety really depends on epub correctness first.

[Turtle91]

coolio! Thanks!!