Choice between epub and LRF, which do you use?

[Valloric]

Originally Posted by HarryT

But that's not true. One does not list embedded graphics in the manifest.

One most certainly does! If one didn't one would be creating non-conforming epub files that would quite probably fail on numerous devices! A Reading System is not required to present any media not referenced in the OPF file.

I'll refer you to section 2.3 of the Open Packaging Format.

Originally Posted by HarryT

I don't know if ePub does the same, but with Mobi (which also uses OPF files), if you include your graphics files in the manifest, they end up being included twice in the book. The fact that they are linked to is sufficient to build them into the book. I know that ePub is different, in that there's no book "built" as such, but do any adverse effects result from omitting the graphics files from the manifest?

How Mobi does it is completely irrelevant. Mobi is not epub. And adverse effects are most certainly possible, if not probable. I believe that currently ADE handles it, but other Reading Systems may not. I'm sure that a lot of tools designed for epub manipulation & transformation would fail on this error in some way.

ADE handles it because it embeds WebKit which does all the loading. IMO, they point it to the directory structure in the epub file and it loads all the images as they are referenced in the HTML. It (webkit) does not use the OPF directly.

[Valloric]

Originally Posted by netseeker

Why not? According to the OPF-spec one *should* list all graphics (as well as font files) in the manifest.

There is no "should". The spec is very specific and uses the word "must". It's not a matter of choice.

[netseeker]

Originally Posted by Valloric

There is no "should". The spec is very specific and uses the word "must". It's not a matter of choice.

Yes you are right. It's not a matter of choice according to the specification but at least a matter of what current reading applications do support.

[HarryT]

Originally Posted by Valloric

One most certainly does! If one didn't one would be creating non-conforming epub files that would quite probably fail on numerous devices! A Reading System is not required to present any media not referenced in the OPF file.

Do you actually know of a device that it would fail on?

It's not "irrelevent" what Mobi does if you wish to create source which can be built for both Mobi and ePub, and if ePub works without the graphics files being listed in the manifest section of the OPF file, I have to ask "does it matter, at a practical level?"

Standards are all very nice, but in reality one goes with what works. If web browsers, for example, were only to display web sites which rigorously conformed to HTML standards, there wouldn't be many that would work.

[Valloric]

Originally Posted by HarryT

Can you name a device that it would fail on, please?

I have no intention of testing each and every device out there to see if it fails on this specific issue. The whole point of a defined standard is that one doesn't need to check how their books display on all devices: one just needs to check against the standard.

Originally Posted by HarryT

It's not "irrelevent" what Mobi does if you wish to create source which can be built for both Mobi and ePub, and if ePub works without the graphics files being listed in the manifest section of the OPF file, I have to ask "does it matter, at a practical level?"

Yes it does. You can not state that "ePub works without the graphics files being listed in the manifest section of the OPF file". ADE works with this error present. Maybe other Reading Systems handle it too. But others don't. They don't have to. Future Reading Systems may not handle it either.

If you don't list all you files in the manifest, you are disregarding the whole point of that section. There are numerous tools out there that convert or transform the epubs in some way and they don't employ HTML renderers. They will break on this. If you for instance feed an epub file to a converter that checks only the OPF file (which it should do), the conversion will fail.

Harry, during my time here on MobileRead you have come across as a very intelligent person. I obviously do not know how to convince you to follow the prescribed standard. Honestly, I'm amazed that I even have to.

I will tell you that if you make epub books with this error you--or someone else using your books--will most definitely encounter a system that will fail in some way because of it.

I guarantee it.

Please do not ignore the manifest, or any other part of the epub spec.

[Valloric]

Originally Posted by HarryT

Standards are all very nice, but in reality one goes with what works. If web browsers, for example, were only to display web sites which rigorously conformed to HTML standards, there wouldn't be many that would work.

With web browsers, you have to make concessions against the standard because some browsers don't implement them correctly. You don't have a choice. With epub, ADE implements the correct behaviour if you create a compliant OPF. You want to create a non-compliant epub file and justify it with "but this works too".

A compliant epub works just as well. Use that.

[HarryT]

Originally Posted by Valloric

If you don't list all you files in the manifest, you are disregarding the whole point of that section. There are numerous tools out there that convert or transform the epubs in some way and they don't employ HTML renderers. They will break on this. If you for instance feed an epub file to a converter that checks only the OPF file (which it should do), the conversion will fail.

I am talking here about images displayed in HTML pages, via <img> tags. Any ePub renderer or converter, no matter how it works, has got to parse those links and hence will "know" that the file is required.

Images which are not referenced in an HTML page are, of course, an entirely different matter. They do of course need to be listed in the manifest in order to be included in the book.

[Valloric]

Originally Posted by HarryT

I am talking here about images displayed in HTML pages, via <img> tags. Any ePub renderer or converter, no matter how it works, has got to parse those links and hence will "know" that the file is required.

No. No it doesn't. Why would it?

All the images are listed in the manifest. You parse that, follow the links in that manifest (because they're there; they have to be, it's in the spec) and you just add those files to whatever new container you are filling up.

No need to write an HTML parser. Saves a ton of work. For some strange reason, I get the feeling that was the whole point of the manifest section: you can get to all the files in the publication without having to go through all the HTML files and scan them line by line.

[HarryT]

I think we're talking slightly at cross purposes here. I'm talking about rendering an ePub file. Any ePub renderer has, by definition, to be able to render HTML and hence will be able to handle image links.

[Valloric]

Originally Posted by HarryT

I think we're talking slightly at cross purposes here. I'm talking about rendering an ePub file. Any ePub renderer has, by definition, to be able to render HTML and hence will be able to handle image links.

But a lot of people will be using (and are currently using) epub for storage purposes. Or just as a base for conversion into future formats. There are numerous other formats (and I'm sure more will come with time) that use (X)HTML for storing text that is then wrapped up with images and whatnot into some container format (like OCF). If I wanted to convert my epub into this other format, I don't need to parse the HTML: I just convert the file structure, write their version of the OPF etc. I would use the OPF in the epub to discover all the images (and other resources) that need to be copied over, or sent to some other, more specific per-MIME-type converter.

You can not ignore these needs. People will download your epub files and assume (rightly so) that they conform to the standard. These files will fail in their current or future pipeline.

Also, assuming how their implementation of a render will look like is a bad idea. Maybe the image files (or other resources) are extracted to some other temporary location not in the archived epub tree and are loaded from there upon request? You would get the links to those images from the OPF. This would also fail with your error.

Harry, your position is sadly indefensible.

[netseeker]

As a software developer i've to admit that i wouldn't implement a (X)HTML-parser (as well as a much simpler parser for DTBook based documents) if i would have to implement a ePub2SomethingElse converter. I would just scan the manifest for all required files of the publication as Valloric pointed out.
If i would have to implement a ePub renderer then i would parse and interpret all permitted media elements contained in the xhtml or dtbook files. But if a used media type isn't one of the OPS core media types and my application (or the device) is not able to support that certain media type, then i would have to read the manifest because according to the specification the manifest must contain an alternative fallback for that media then.

[Valloric]

Originally Posted by netseeker

But if a used media type isn't one of the OPS core media types and my application (or the device) is not able to support that certain media type, then i would have to read the manifest because according to the specification the manifest must contain an alternative fallback for that media then.

I thought of that too, but Harry could argue against that with "I would always only link to core OPS media types" and that wouldn't break with this specific issue in mind.

All other issues still stand though.

[DixieGal]

"- Start using epub but don't worry about converting stuff I already have---again, cross that bridge when or if I need to."


If someday in the far future I am unable to re-read the older stuff, well, I guess I'll just have to read something else. I almost never re-read, so don't see this as a problem.

[JSWolf]

The reason the fonts do not need to be listed in the OPF is that they get pulled in via the CSS and the OPF doesn't actually need to know they are there. The CSS needs to know so it can pull them in specify where to use them.

[Valloric]

Originally Posted by JSWolf

The reason the fonts do not need to be listed in the OPF is that they get pulled in via the CSS and the OPF doesn't actually need to know they are there. The CSS needs to know so it can pull them in specify where to use them.

Do we need to have this whole discussion again? The fonts need to be in the OPF. Everything needs to be in the OPF, except the files that define the OPF itself.

Go through the whole discussion and replace the word "image" with the word "font". The result is the same.