Quote:
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.