Bob:
After updating to the latest snapshot I'm getting validation errors that I don't know if they are epubcheck issues or if they are being caused by the change in base.dir behavior:
I build the html content like this (ant task)
<exec executable="${xsltproc_bin}">
<arg line="--stringparam base.dir book/ carlos-chunk.xsl ${src_file}.xml"/>
</exec>
Realized earlier that I had OEBPS as the base.dir and changed it to book/
With that change made I'm getting epubcheck validation errors that were not there before:
epub-check:
[java] ERROR: docbook-howto.epub: Length of the first filename in archive must be 8, but was 13
[java] Epubcheck Version 3.0
[java]
[java] ERROR: docbook-howto.epub: Required META-INF/container.xml resource is missing
[java]
[java] Check finished with warnings or errors
[java]
I got the validations errors with both epubcheck 3.0 B5 and 3.0 final.
I'm trying to determine if the errors are caused by the update to the base.dir parameter or if it's a new quirk of epubcheck that I hadn't seen before.
Carlos
On Thu, Apr 11, 2013 at 3:27 PM, Bob Stayton <> wrote:
I figured out a better way to handle this. The HTML stylesheets already have an internal variable named 'chunk.base.dir' that actually used for chunking. It originally ensured that the base.dir value had a trailing slash. I've modified it for epub3 to append the value of $epub.oebps.dir, which is 'OEBPS' by default.
So in the next release you can set base.dir has you usually do, and the OEBPS is automatically added for the files that need it. For those transitioning from the current version, the process will fail with an explanatory message if your $base.dir includes the OEBPS part. Then you can reset your $base.dir to omit the OEBPS part.
Bob Stayton
Sagehill Enterprises
--------------------------------------------------
From: "Bob Stayton" <>
Sent: Wednesday, April 10, 2013 10:53 AM
To: "Mike Cook" <>; <>
Subject: Re: [docbook-apps] EPUB3: how to use base.dir ?
Thanks for the feedback. I think maintaining a confusing base.dir setup is worse than any backwards compatibility issues for the next release, so I'll fix this. Since the base.dir param is already used in many places in the html stylesheets, changing its behavior would be difficult. I like the idea of a new epub.base.dir param, and the stylesheet would set the default base.dir value to
concat($epub.base.dir, '/', $epub.oebps.dir)
Regarding those params, only these are hardwired constants and should be xsl:variables:
epub.metainf.dir='META-INF/'
epub.mimetype.filename='mimetype'
epub.mimetype.value='application/epub+zip'
These can be changed by the user:
epub.oebps.dir='OEBPS'
epub.ncx.filename='toc.ncx'
epub.container.filename='container.xml'
epub.package.filename='package.opf'
I'm not sure why you would change them, but they can be changed and still have a valid epub file.
Bob Stayton
Sagehill Enterprises
--------------------------------------------------
From: "Mike Cook" <>
Sent: Wednesday, April 10, 2013 10:24 AM
To: <>
Subject: Re: [docbook-apps] EPUB3: how to use base.dir ?
I agree that the current base.dir is very confusing and it should be changed so that it becomes the directory in which all the EPUB files are located. e.g. "foo".
> Changing it for the next release would break existing implementations,
> though, but it might be worth it.
>> IF we want to do that, then better sooner than later.
I believe it should be changed.
One question that bothers me with the params is why it's even possible to change things like the META-INF directory?
epub.oebps.dir='OEBPS'
epub.metainf.dir='META-INF/'
epub.ncx.filename='toc.ncx'
epub.mimetype.filename='mimetype'
epub.mimetype.value='application/epub+zip'
epub.container.filename='container.xml'
epub.package.filename='package.opf'
I can't see a single reason why any of these should be named anything else. Obviously some can't be, but even OEBPS can be considered a constant in my eyes.
Mike
On 10/04/2013 16:17, Thomas Schraitle wrote:
Hi Bob,
thanks for your answer.
On Tue, 9 Apr 2013 09:28:09 -0700
"Bob Stayton" <> wrote:
Try setting base.dir to "foo/OEBPS/". That will put META-INF,
mimetype, and OEBPS in foo/, which is what I think you want.
Yes, that works. :)
As you know, the stylesheets write HTML output to $base.dir. The
default setting for base.dir in epub3 is "OEBPS/". For the other
epub files that are not in the HTML output directory, they are
written relative to base.dir. That's how it was done in the Epub2
stylesheet, and the Epub3 stylesheet maintained it for backward
compatibility.
In that case, I think the behaviour of both is highly unfortunate.
Usually, if a user defines a base directory, you normally don't expect
that a stylesheet writes to its parent(!) directory. As you probably
know, this is what a user gets:
Writing foo/OEBPS/.....
Writing foo/OEBPS/package.opf for book(dblayouttest)
Writing foo/OEBPS/../META-INF/container.xml for book(dblayouttest)
Writing foo/OEBPS/../mimetype for book(dblayouttest)
Generating NCX file ...
Theoretically, if a user sets base.dir to the "wrong" path, writing to
its parent directory could be forbidden due to missing permissions.
My assumption was that the filenames are built by concatenating
$base.dir with the rest. This is exactly what the HTML stylesheets do.
This could probably have been more clearly configured by leaving the
default base.dir empty and instead defining a new param for the OEBPS
directory name that would be appended to base.dir. Changing it for
the next release would break existing implementations, though, but it
might be worth it.
Not sure if we want break backward compatibility or not. I think the
current implementation is confusing. IF we want to do that, then better
sooner than later.
Or, maybe invent some new variable and name it epub.base.dir which
serves as "the" base directory for everything. :)
Apart from the issue with base.dir, I have some additional points:
1. Parameter vs. Variables?
The EPUB3 stylesheet contains the following parameters:
epub.oebps.dir='OEBPS'
epub.metainf.dir='META-INF/'
epub.ncx.filename='toc.ncx'
epub.mimetype.filename='mimetype'
epub.mimetype.value='application/epub+zip'
epub.container.filename='container.xml'
epub.package.filename='package.opf'
If I'm not mistaken, these parameters looks like constants. Isn't it
better to define them as variables?
Parameters give the (wrong?) impression that they can be changed. I'm
not sure if the OEBPS directory can be named differently, but I guess
the parameters with epub.mimetype.value and epub.mimetype.filename stay
always the same.
What does the EPUB3 spec says here?
2. Creating Manifest
Currently, the parameter generate.manifest is set to 0, deactivating
the manifest file.
I think it could be useful to have a manifest with *everything* in it
(be it images, callout and admon graphics as well as HTML files and the
EPUB3 files).
For example, such a manifest file could be used as an input file for
other tools copying callouts and admon graphics automatically etc.
Just my 2 cents... :)
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
