Re: images subdirectories in epub

[Patrice Dumas]

On Wed, Aug 03, 2022 at 03:08:09PM -0700, Per Bothner wrote:
> 
> 
> On 8/3/22 14:01, Patrice Dumas wrote:
> > On Wed, Aug 03, 2022 at 12:16:04PM -0700, Per Bothner wrote:
> > > Again - why? More specifically: why are you putting the html/xhtml file 
> > > in a
> > > separate xhtml subdirectory?  If you get rid of that, it seems you avoid 
> > > the problem.
> > 
> > No, the problem is not avoided, because the additional image
> > subdirectory is still not created.
> 
> Agreed: when I generate HTML my Makefile has to explicitly copy over the 
> image files.
> It would probably be better to have tex2any do that by default (or as an 
> option
> if we're concerned about compatibility).  Even more-so for epub: Whether 
> texi2any
> creates the epub file directly or uses a separate script, that script needs 
> to copy
> over the image files before creating the epub archive.

It is how it is implemented, in EPUB (but not in HTML), images are
copied, but it was buggy.  Now this has been fixed, not by adding a
directory, but by removing the subdirectory used in @image.

> The primary use-case for generating epub is to support e-readers, but another
> useful application is as a compressed container format for the html 
> represention
> of a manual.  For example an application or server could store the manual
> as an epub file, and then map http requests to members of the epub archive.
> (A server doesn't even have to uncompress the member, but can send it
> compressed to a browser that understands gzip compression.  I implemented
> this for the libwebsockets library.)

For this use case, the files would need to be directly in the top level
directory, though?  Although conforming, that would be a very messy
organization for an EPUB container, I think.

> A related use-case is to use epub as a distribution format for manuals.
> Installation is then just a matter of running unzip.

Wouldn't it be simpler to generate the html as usual and zip the
directory instead of generating EPUB?  EPUB has features that make it
quite specific, quite a bit of meta informations that makes it look
quite strange, and very unlike HTML.  And the generated xhtml lacks
features, for instance, there is no navigation information, which makes
the resulting xhtml quite useless not in an EPUB where the spine and
nav informations are the sources for the navigation information.  The
EPUB philosophy is also to contain all the referenced material, which is
quite unlike the web (and we cannot do that in Texinfo EPUB output).

> In these applications, it is useful that the structure of the epub archive
> mirrors the preferred layout of a directory for web-browsing. This also
> reduces the risk of errors and inconsistencies, I believe.

I disagree, the EPUB is not organized as a web site, with hyperlinks, it
is a book with a cover, a linear organization and a table of contents.
Trying to make it fit both paradigms seems incorrect to me.

> The "index.html" (or index.xhtml) file should be in the top directory.
> It is easier and traditionally if the other pages are in the same directory.
> Similarly, images should either be in the same directory as index.html
> (and the other html files) or in a sub-directory - *not* in a sibling 
> directory.

There is no index.html nor index.xhtml file when outputting EPUB.  It
did not seems to me to be useful at all, again it is like a book not a
website.  It could have a cover, a table of content, a colophon, but
an index.xhtml that would be the starting point for browsing does not
seems to me to fit the EPUB philosophy, even though it is visible that
EPUB tries to not to be only for books, but also for comics, mangas,
less linear teaching material, and maybe other styles.

-- 
Pat