On Sun, Oct 23, 2022 at 05:53:01PM +0100, Gavin Smith wrote: > On Sun, Oct 23, 2022 at 04:47:50PM +0200, [email protected] wrote: > > > > I tracked it down to tp/ext/epub3.pm and there is actually already a > > FIXME, I knew that something like that was bound to happen: > > > > # FIXME INFO_JS_DIR is used both as a filesystem directory name > > # and as path in document, as a path in document '../' should be > > # used whatever File::Spec->updir() is. > > > > To me the basic issue is that INFO_JS_DIR is used, in HTML.pm in > > output(), both as an HTML path l 8941 and to copy local files near l > > 10184 of HTML.pm. As a local file path, it would make sense to > > use backward slash, but not as HTML path. > > In HTML.pm, File::Copy is used to copy the files. It's possible > that forward slashes would work on all relevant OS's, in which case > we can hard-code a forward slash in ext/epub3.pm. I believe that > forward slashes work in most places on MS-Windows as a directory > separator, except on the command line. > > Does it even make sense to use INFO_JS_DIR for EPUB output? Do EPUB > readers do anything with the JavaScript files?
In theory, the javascript could be interpreted by the EPUB readers. It is explicitely described in the standard. In practice the results are not pretty for the javascript in Texinfo, but this is something that should be possible. -- Pat
