OEBPS validation error

[kerliza]

In Sigil Flight crew validation check I am seeing one error I can't locate in one html file making up a chapter. It appears simple:

OEBPS N/A This resource is reachable but not present in the OPF <manifest>. "Reachable" means that a reference of some kind that points to this resource exists in the epub.

Any suggestions where to begin? I've combed through the content.opf and the successfully cleaned chapters mirror the structure closely with the problematic file. I have found no other problems like this online after hours of searching that appear this basic or possibly global.

[mrmikel]

You could have a space in the name or it could be in capital letters. Try searching for a fragment of the name.

You could also try running it through the online epubcheck and it might give you a different and maybe more useful message.

[theducks]

Could be ANYWHERE (I never understood why it could not report the 'first found' since it was "reachable")

Certain (unknown) operations leave remnants in the OPF, so remember to look there (and the NCX if you did not have Sigil create a fresh TOC)

(old) HTML TOC is another place that filenames appear

[DiapDealer]

Check all links in the text. There could be one with a mispelling or capitalization problem like mrmikel mentioned.

Usually, it's a link to file that just doesn't exist in the epub. Focus on the html toc and/or the toc.ncx first. That's where the most links usually are. Then expand outward to things like footnote links, header links (back to the html toc), and any other links that may or may not be included in the text of your book.

If all else fails, search for "href=" with Find & Replace, and verify each and every occurence.

There may be a Sigil Report that helps with links as well (I'm away from Sigil and can't remember for sure).

[theducks]

Originally Posted by DiapDealer

Check all links in the text. There could be one with a mispelling or capitalization problem like mrmikel mentioned.

Usually, it's a link to file that just doesn't exist in the epub. Focus on the html toc and/or the toc.ncx first. That's where the most links usually are. Then expand outward to things like footnote links, header links (back to the html toc), and any other links that may or may not be included in the text of your book.

If all else fails, search for "href=" with Find & Replace, and verify each and every occurence.

There may be a Sigil Report that helps with links as well (I'm away from Sigil and can't remember for sure).

You may be thinking of the 'Links' section of Tools: Reports

IIRC that will NOT include looking at any non-html files (NCX, OPF)

[kerliza]

Originally Posted by mrmikel

You could have a space in the name or it could be in capital letters. Try searching for a fragment of the name.

You could also try running it through the online epubcheck and it might give you a different and maybe more useful message.

Thanks for directing me to the online validator!

I ran the file through the EPUB Validator at http://validator.idpf.org/
and found the error line for the omission. Earlier in developing the chapter I had tested an html file in Text/Section0001.xhtml and then deleted it losing the content between quote marks. The error created by doing that was altering the toc so it could not point to the first html file:
<content src="" /> in toc.ncx

The correction was to copy from a "NO PROBLEMS FOUND" Epub and the file was thereafter successfully flightcrew validated with the line: <content src="Text/Section0001.xhtml"/>

I have postponed working with toc formation because the project is in a fluid state presently. The ncx is not a file I have combed before as I am new to Sigil. That hurdle is yet ahead.

[kerliza]

Originally Posted by DiapDealer

Check all links in the text. There could be one with a mispelling or capitalization problem like mrmikel mentioned.

Usually, it's a link to file that just doesn't exist in the epub. Focus on the html toc and/or the toc.ncx first. That's where the most links usually are. Then expand outward to things like footnote links, header links (back to the html toc), and any other links that may or may not be included in the text of your book.

If all else fails, search for "href=" with Find & Replace, and verify each and every occurence.

There may be a Sigil Report that helps with links as well (I'm away from Sigil and can't remember for sure).

Yes, I did comb all the links in the Sigil Report and all were valid. I spent over 16 hours trying to find the problem before I posted on this forum. You were right in directing me to focus on the toc.ncx as the problem was in the content src file name being absent.

Thanks for your suggestion.

[kerliza]

I ran the file through the online validator (barely made it as the file was 9.5Mb with a limitation of 10Mb max) and found the error.

Also popping into the error list were long file names used for images. Is there an instance in creating EPUBs where long file names with spaces are rejected? Must I close the spaces in the hundreds of image files created to date that are being placed in Sigil to clear hurdles for use in various e-readers?

If so, what program is best used to bulk process file name changes that saves into Sigil using an external pic editor?

[mrmikel]

As I recall you can use the bulk rename function in Sigil itself. It will destroy the existing names, but it will fix the names where they are found in the epub, so the epub will work just fine.

Highlight the file names in the images folder and right click to select rename and it will give you a dialog box, so that you can choose the base name such as picture, image, etc followed by sequential numbers.

Linux is not fond of spaces in file names and Linux runs by Sony PRS-300 anyway.

[PeterT]

Originally Posted by mrmikel

Linux is not fond of spaces in file names and Linux runs by Sony PRS-300 anyway.

That's the first time I've seen that claim..... Sure at the command line you have to prefix the space in the filename by a \ but I'm not at all sure that means Linux is not fond of spaces.

[kerliza]

I used the Sigil process for one set of image files in a chapter (which made a huge task for reentering the "alt image" labels) but in merging the separately managed chapters into one epub the images regrouped according to alpha-numeric ordering to become a unanimous mess.

I'll have to work on the approach to have 11 chapters with a compilation of 500 pictures make sense for fine editing when there is no way to separate the images into distinct folders. One mistake and raking through the image list will be monstrous given the limitations of the search feature for image management.

What would be cool is if the images could be given separate folders to correspond to their parent chapter in Sigil.

Image archiving will be an ongoing task in this century due to the collage collections of the past that have historical significance to every community since photography began. E-publishing has to form a path in expecting the future of image management for story illustration will be a flourishing industry.

In the meantime, bulk renaming in Sigil has been daunting in trying to find a way to do it without losing the original image name which distinguishes it at a glance; a substitution I find handy given there is not a thumbnail feature in Sigil for visual image recognition ordering. The insert feature is a tedious image search approach.

Musing the mussiness

[mrmikel]

Originally Posted by PeterT

That's the first time I've seen that claim..... Sure at the command line you have to prefix the space in the filename by a \ but I'm not at all sure that means Linux is not fond of spaces.

Thanks for clarifying this Peter. It was probably a limitation of the particular program or a lack of knowledge that the backslash would work. In a practical sense, going back and forth between Windows and Linux and throwing in backslashes probably is an invitation to confusion for me.

[mrmikel]

Kerliza,

It might be possible to structure an epub this way, with additional image folders. It is just that Sigil doesn't support infinite variations in doing so. They wanted to be sure that anything produced was valid, so it is limited in its possible output as I understand it. It is already a million line program, and the idea of a ten million line program might have had not so much appeal to the developers.

You might be able to accomplish this in a way I have seen it done in some other books - by file name. A possible might be ch1Image1, ch1Image2, etc. Not elegant but it might be possible. You might select just a chapter's worth at a time and use the ch1, etc at the base as they get renamed. But it isn't going to give you descriptive names.

A clunky but useable work around could be to unzip the epub file to a work directory and open a graphics program which has a preview function which would allow to roll over each name and see the image.

[Jellby]

You can also use quotes:

$ rm "file name with spaces.txt"

But spaces in filenames are generally a "Bad Idea"™. Not all programs are designed with them in mind, and you'll be finding bugs every now and then.

[theducks]

Originally Posted by kerliza

I used the Sigil process for one set of image files in a chapter (which made a huge task for reentering the "alt image" labels) but in merging the separately managed chapters into one epub the images regrouped according to alpha-numeric ordering to become a unanimous mess.

I'll have to work on the approach to have 11 chapters with a compilation of 500 pictures make sense for fine editing when there is no way to separate the images into distinct folders. One mistake and raking through the image list will be monstrous given the limitations of the search feature for image management.

What would be cool is if the images could be given separate folders to correspond to their parent chapter in Sigil.

Image archiving will be an ongoing task in this century due to the collage collections of the past that have historical significance to every community since photography began. E-publishing has to form a path in expecting the future of image management for story illustration will be a flourishing industry.

In the meantime, bulk renaming in Sigil has been daunting in trying to find a way to do it without losing the original image name which distinguishes it at a glance; a substitution I find handy given there is not a thumbnail feature in Sigil for visual image recognition ordering. The insert feature is a tedious image search approach.

Musing the mussiness

Why would renaming the image file make Alt= need work??

Alt= Should be a descriptive of the Image or "" for decorations

good
alt="Cover"
better
alt="Girl in tiny Red Bikini on a bright, sandy beach"
alt= is not a place to just repeat the files name (frequently seen)