docbook-apps

Hi,

this is a follow-up from my last mail about EPUB2*, however in
regards to the EPUB3 stylesheets (version 1.78.1). Maybe I miss
something important. Anyway, here is the situation:


1. Using EPUB3 Stylesheets with default values

Running xsltproc without any customization nor parameters:
$ xsltproc $DB/epub3/chunk.xsl epub_booktest.xml

This gives me the following structure in my current directory:
+-- META-INF
|   +-- container.xml
|-- mimetype
+-- OEBPS
|-- *.html
|-- package.opf
+-- toc.ncx


2. Using EPUB3 Stylesheets with base.dir

Running xsltproc with parameters base.dir:
$ xsltproc --stringparam base.dir "foo/" \
$DB/epub3/chunk.xsl epub_booktest.xml

This gives me the following structure in my current directory:
+-- foo
  | +-- *.html
|   |-- package.opf
|   +-- toc.ncx
+-- META-INF
|   +-- container.xml
+-- mimetype


Using the stylesheets without any parameter, you get all files in the
current directory, which is fine.
However, my impresssion was to set the output directory for *all* files
with the base.dir parameter. This directory is only concatenated to
HTML files, not the other files.

Is this a conceptual design descision or is it a bug? How can I collect
*all* files in *one* directory?

Thanks. :-)


---
* Subject: "Conceptual Questions and Customizations Regarding EPUB2
Stylesheets"


--
Gruß/Regards,
Thomas Schraitle

Hi,
Try setting base.dir to "foo/OEBPS/". That will put META-INF, mimetype, and
OEBPS in foo/, which is what I think you want.

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.

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.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

--------------------------------------------------
From: "Thomas Schraitle" <tom_schr@web.de>
Sent: Tuesday, April 09, 2013 6:49 AM
To: <docbook-apps@lists.oasis-open.org>
Subject: [docbook-apps] EPUB3: how to use base.dir ?

> Hi,
>
> this is a follow-up from my last mail about EPUB2*, however in
> regards to the EPUB3 stylesheets (version 1.78.1). Maybe I miss
> something important. Anyway, here is the situation:
>
>
> 1. Using EPUB3 Stylesheets with default values
>
> Running xsltproc without any customization nor parameters:
> $ xsltproc $DB/epub3/chunk.xsl epub_booktest.xml
>
> This gives me the following structure in my current directory:
> +-- META-INF
> | +-- container.xml
> |-- mimetype
> +-- OEBPS
> |-- *.html
> |-- package.opf
> +-- toc.ncx
>
>
> 2. Using EPUB3 Stylesheets with base.dir
>
> Running xsltproc with parameters base.dir:
> $ xsltproc --stringparam base.dir "foo/" \
> $DB/epub3/chunk.xsl epub_booktest.xml
>
> This gives me the following structure in my current directory:
> +-- foo
> | +-- *.html
> | |-- package.opf
> | +-- toc.ncx
> +-- META-INF
> | +-- container.xml
> +-- mimetype
>
>
> Using the stylesheets without any parameter, you get all files in the
> current directory, which is fine.
> However, my impresssion was to set the output directory for *all* files
> with the base.dir parameter. This directory is only concatenated to
> HTML files, not the other files.
>
> Is this a conceptual design descision or is it a bug? How can I collect
> *all* files in *one* directory?
>
> Thanks. :-)
>
>
> ---
> * Subject: "Conceptual Questions and Customizations Regarding EPUB2
> Stylesheets"
>
>
> --
> Gruß/Regards,
> Thomas Schraitle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>

Hi Bob,

thanks for your answer.

On Tue, 9 Apr 2013 09:28:09 -0700
"Bob Stayton" <bobs@sagehill.net> 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... :)


--
Gruß/Regards,
Thomas Schraitle

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" <bobs@sagehill.net> 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... :)
>
>

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
bobs@sagehill.net

--------------------------------------------------
From: "Mike Cook" <m@mikecook.co.uk>
Sent: Wednesday, April 10, 2013 10:24 AM
To: <docbook-apps@lists.oasis-open.org>
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" <bobs@sagehill.net> 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: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>

Hi Bob,

Am Mittwoch, 10. April 2013, 10:53:17 schrieb Bob Stayton:
>
> > Or, maybe invent some new variable and name it epub.base.dir which
> > serves as "the" base directory for everything.
>
> 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)

Great!! Thanks a million!


> 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'

Right, sounds reasonable.


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

Ok, I'm fine with that. :)


Thanks for all your efforts.


--
Gruß/Regards
Thomas Schraitle

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
bobs@sagehill.net

--------------------------------------------------
From: "Bob Stayton" <bobs@sagehill.net>
Sent: Wednesday, April 10, 2013 10:53 AM
To: "Mike Cook" <m@mikecook.co.uk>; <docbook-apps@lists.oasis-open.org>
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
> bobs@sagehill.net
>
> --------------------------------------------------
> From: "Mike Cook" <m@mikecook.co.uk>
> Sent: Wednesday, April 10, 2013 10:24 AM
> To: <docbook-apps@lists.oasis-open.org>
> 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" <bobs@sagehill.net> 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: docbook-apps-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>

Hi,

Am Donnerstag, 11. April 2013, 15:27:14 schrieb Bob Stayton:
> 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.

This is great news! Thanks!

I would like to suggest an additional idea:

Currently, the "DocBook XSL Stylesheets: Reference Documentation"[1] contains
all the parameters for HTML, FO, manpages, etc. Wouldn't it make sense to
include the EPUB2/3 parameters too?

Most of the parameters are already documented (refering to HTML). However,
there are some parameters which are specific to EPUB. It would be helpful if
users know what can be adapted.


[1] http://docbook.sf.net/release/xsl/current/doc/index.html

--
Gruß/Regards
Thomas Schraitle

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 <bobs@sagehill.net> 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
> bobs@sagehill.net
>
> ------------------------------**--------------------
> From: "Bob Stayton" <bobs@sagehill.net>
> Sent: Wednesday, April 10, 2013 10:53 AM
> To: "Mike Cook" <m@mikecook.co.uk>; <docbook-apps@lists.oasis-**open.org<docbook-apps@lists.oasis-open.org>
> >
> 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
>> bobs@sagehill.net
>>
>> ------------------------------**--------------------
>> From: "Mike Cook" <m@mikecook.co.uk>
>> Sent: Wednesday, April 10, 2013 10:24 AM
>> To: <docbook-apps@lists.oasis-**open.org<docbook-apps@lists.oasis-open.org>
>> >
>> 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" <bobs@sagehill.net> 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: docbook-apps-unsubscribe@**lists.oasis-open.org<docbook-apps-unsubscribe@lists.oasis-open.org>
>>> For additional commands, e-mail: docbook-apps-help@lists.oasis-**
>>> open.org <docbook-apps-help@lists.oasis-open.org>
>>>
>>>
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: docbook-apps-unsubscribe@**lists.oasis-open.org<docbook-apps-unsubscribe@lists.oasis-open.org>
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-**open.org<docbook-apps-help@lists.oasis-open.org>
>>
>>
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@**lists.oasis-open.org<docbook-apps-unsubscribe@lists.oasis-open.org>
> For additional commands, e-mail: docbook-apps-help@lists.oasis-**open.org<docbook-apps-help@lists.oasis-open.org>
>
>

Hi Carlos,

Am Samstag, 20. April 2013, 18:16:42 schrieb Carlos Araya:
>
> 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:

According to the snapshots.docbook.org page, the last version is built on
April 17. This looks not as the latest snapshot release. ;-)

However, I've tried to transform my cookbook project into EPUB3 and received
validation errors too (but they are different). But this is another story.


> [...]
> Realized earlier that I had OEBPS as the base.dir and changed it to book/

Right, that's correct now.


> With that change made I'm getting epubcheck validation errors that were not
> there before:

Tip: You don't need to create the ZIP archive and pass it to epubcheck. You
can start the validation process right after xsltproc wrote the directories
without creating the ZIP archive.

For example, if you've used foo/ as base.dir, invoke epubcheck with this
option after the transformation step:

$ epubcheck foo/ -mode exp

It is even possible to validate only parts of the EPUB (directory), also with
the -mode option:

mo = Media overlays
nav = Navigation document
opf = package document
svg = SVG content
xhtml = XHTML content

The -version option specifies with EPUB version to validate (the values can be
either 2.0 or 3.0).


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

This indeed looks strange. However, I didn't get such validation errors. I've
used the last public stable release (1.78.1) and the snapshot from docbook-
xsl-snapshot.tar.bz2 file, both with success.

Do you use a customization layer?



--
Gruß/Regards
Thomas Schraitle

Thomas:

The build file I use was working without errors until I made the change.

The problem with generating the content zip file is not just validation.
Either before or after I validate the file I will still have to generate
the zipped epub file to deliver so, to me, the problem is still there and
it wasn't there before.

I use JIng to validate the docbook file before transformation and it
reports no errors.

I work with the following customization layer


<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:import href="../docbook/epub3/chunk.xsl"/>


<xsl:param name="html.stylesheet" select="'carlos-new.css'"/>


<xsl:param name="epub.include.optional.metadata.dc.elements"
select="1"/>


<xsl:param name="kindle.extensions" select="1"/>


<xsl:param name="admon.graphics" select="1"/>


<xsl:param name="callout.graphics.extension">.png</xsl:param>
<xsl:param name="callout.graphics.path">images/callouts/</xsl:param>
<xsl:param name="callout.graphics" select="1"></xsl:param>


<xsl:param name="chunk.section.depth" select="0"/>
<xsl:param name="chunk.first.sections" select="0"/>


<xsl:template name="user.manifest.items">
<item xmlns="http://www.idpf.org/2007/opf" id="font1"
href="type/GraublauWeb.otf" media-type="application/vnd.ms-opentype"/>
<item xmlns="http://www.idpf.org/2007/opf" id="font2"
href="type/GraublauWebBold.otf" media-type="application/vnd.ms-opentype"/>
<item xmlns="http://www.idpf.org/2007/opf" id="font3"
href="type/DejaVuSansMono.ttf" media-type="application/vnd.ms-opentype"/>
</xsl:template>
</xsl:stylesheet>

Carlos

On Sat, Apr 20, 2013 at 11:16 PM, Thomas Schraitle <tom_schr@web.de> wrote:

> Hi Carlos,
>
> Am Samstag, 20. April 2013, 18:16:42 schrieb Carlos Araya:
> >
> > 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:
>
> According to the snapshots.docbook.org page, the last version is built on
> April 17. This looks not as the latest snapshot release. ;-)
>
> However, I've tried to transform my cookbook project into EPUB3 and
> received
> validation errors too (but they are different). But this is another story.
>
>
> > [...]
> > Realized earlier that I had OEBPS as the base.dir and changed it to book/
>
> Right, that's correct now.
>
>
> > With that change made I'm getting epubcheck validation errors that were
> not
> > there before:
>
> Tip: You don't need to create the ZIP archive and pass it to epubcheck. You
> can start the validation process right after xsltproc wrote the directories
> without creating the ZIP archive.
>
> For example, if you've used foo/ as base.dir, invoke epubcheck with this
> option after the transformation step:
>
> $ epubcheck foo/ -mode exp
>
> It is even possible to validate only parts of the EPUB (directory), also
> with
> the -mode option:
>
> mo = Media overlays
> nav = Navigation document
> opf = package document
> svg = SVG content
> xhtml = XHTML content
>
> The -version option specifies with EPUB version to validate (the values
> can be
> either 2.0 or 3.0).
>
>
> > 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.
>
> This indeed looks strange. However, I didn't get such validation errors.
> I've
> used the last public stable release (1.78.1) and the snapshot from docbook-
> xsl-snapshot.tar.bz2 file, both with success.
>
> Do you use a customization layer?
>
>
>
> --
> Gruß/Regards
> Thomas Schraitle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>

The latest snapshot is from 22 April, so you should try that version and let us know if something still needs fixing.

Something is going wrong with the snapshot machine that prevents it from building a snapshot with each change. I'm investigating.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


From: Carlos Araya
Sent: Sunday, April 21, 2013 8:33 AM
To: Thomas Schraitle
Cc: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] EPUB3: how to use base.dir ?


Thomas:

The build file I use was working without errors until I made the change.

The problem with generating the content zip file is not just validation. Either before or after I validate the file I will still have to generate the zipped epub file to deliver so, to me, the problem is still there and it wasn't there before.

I use JIng to validate the docbook file before transformation and it reports no errors.

I work with the following customization layer


<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:import href="../docbook/epub3/chunk.xsl"/>


<xsl:param name="html.stylesheet" select="'carlos-new.css'"/>


<xsl:param name="epub.include.optional.metadata.dc.elements" select="1"/>


<xsl:param name="kindle.extensions" select="1"/>


<xsl:param name="admon.graphics" select="1"/>


<xsl:param name="callout.graphics.extension">.png</xsl:param>
<xsl:param name="callout.graphics.path">images/callouts/</xsl:param>
<xsl:param name="callout.graphics" select="1"></xsl:param>


<xsl:param name="chunk.section.depth" select="0"/>
<xsl:param name="chunk.first.sections" select="0"/>


<xsl:template name="user.manifest.items">
<item xmlns="http://www.idpf.org/2007/opf" id="font1" href="type/GraublauWeb.otf" media-type="application/vnd.ms-opentype"/>
<item xmlns="http://www.idpf.org/2007/opf" id="font2" href="type/GraublauWebBold.otf" media-type="application/vnd.ms-opentype"/>
<item xmlns="http://www.idpf.org/2007/opf" id="font3" href="type/DejaVuSansMono.ttf" media-type="application/vnd.ms-opentype"/>
</xsl:template>
</xsl:stylesheet>

Carlos

On Sat, Apr 20, 2013 at 11:16 PM, Thomas Schraitle <tom_schr@web.de> wrote:

Hi Carlos,

Am Samstag, 20. April 2013, 18:16:42 schrieb Carlos Araya:

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


According to the snapshots.docbook.org page, the last version is built on
April 17. This looks not as the latest snapshot release. ;-)

However, I've tried to transform my cookbook project into EPUB3 and received
validation errors too (but they are different). But this is another story.


> [...]

> Realized earlier that I had OEBPS as the base.dir and changed it to book/


Right, that's correct now.



> With that change made I'm getting epubcheck validation errors that were not
> there before:


Tip: You don't need to create the ZIP archive and pass it to epubcheck. You
can start the validation process right after xsltproc wrote the directories
without creating the ZIP archive.

For example, if you've used foo/ as base.dir, invoke epubcheck with this
option after the transformation step:

$ epubcheck foo/ -mode exp

It is even possible to validate only parts of the EPUB (directory), also with
the -mode option:

mo = Media overlays
nav = Navigation document
opf = package document
svg = SVG content
xhtml = XHTML content

The -version option specifies with EPUB version to validate (the values can be
either 2.0 or 3.0).



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


This indeed looks strange. However, I didn't get such validation errors. I've
used the last public stable release (1.78.1) and the snapshot from docbook-
xsl-snapshot.tar.bz2 file, both with success.

Do you use a customization layer?



--
Gruß/Regards
Thomas Schraitle



---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

Bob,

The latest snapshot, downloaded tonight I get the same validation error.

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]

BUILD FAILED

I then tried to zip and validate he file manually and I got the same error

Carlos

On Mon, Apr 22, 2013 at 10:47 AM, Bob Stayton <bobs@sagehill.net> wrote:

> **
> The latest snapshot is from 22 April, so you should try that version and
> let us know if something still needs fixing.
>
> Something is going wrong with the snapshot machine that prevents it from
> building a snapshot with each change. I'm investigating.
>
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net
>
> *From:* Carlos Araya <carlos.araya@gmail.com>
> *Sent:* Sunday, April 21, 2013 8:33 AM
> *To:* Thomas Schraitle <tom_schr@web.de>
> *Cc:* docbook-apps@lists.oasis-open.org
> *Subject:* Re: [docbook-apps] EPUB3: how to use base.dir ?
>
> Thomas:
>
> The build file I use was working without errors until I made the change.
>
> The problem with generating the content zip file is not just validation.
> Either before or after I validate the file I will still have to generate
> the zipped epub file to deliver so, to me, the problem is still there and
> it wasn't there before.
>
> I use JIng to validate the docbook file before transformation and it
> reports no errors.
>
> I work with the following customization layer
>
>
> <xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
>
> <xsl:import href="../docbook/epub3/chunk.xsl"/>
>
>
> <xsl:param name="html.stylesheet" select="'carlos-new.css'"/>
>
>
> <xsl:param name="epub.include.optional.metadata.dc.elements"
> select="1"/>
>
>
> <xsl:param name="kindle.extensions" select="1"/>
>
>
> <xsl:param name="admon.graphics" select="1"/>
>
>
> <xsl:param name="callout.graphics.extension">.png</xsl:param>
> <xsl:param name="callout.graphics.path">images/callouts/</xsl:param>
> <xsl:param name="callout.graphics" select="1"></xsl:param>
>
>
> <xsl:param name="chunk.section.depth" select="0"/>
> <xsl:param name="chunk.first.sections" select="0"/>
>
>
> <xsl:template name="user.manifest.items">
> <item xmlns="http://www.idpf.org/2007/opf" id="font1"
> href="type/GraublauWeb.otf" media-type="application/vnd.ms-opentype"/>
> <item xmlns="http://www.idpf.org/2007/opf" id="font2"
> href="type/GraublauWebBold.otf" media-type="application/vnd.ms-opentype"/>
> <item xmlns="http://www.idpf.org/2007/opf" id="font3"
> href="type/DejaVuSansMono.ttf" media-type="application/vnd.ms-opentype"/>
> </xsl:template>
> </xsl:stylesheet>
>
> Carlos
>
> On Sat, Apr 20, 2013 at 11:16 PM, Thomas Schraitle <tom_schr@web.de>wrote:
>
>> Hi Carlos,
>>
>> Am Samstag, 20. April 2013, 18:16:42 schrieb Carlos Araya:
>> >
>> > 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:
>>
>> According to the snapshots.docbook.org page, the last version is built on
>> April 17. This looks not as the latest snapshot release. ;-)
>>
>> However, I've tried to transform my cookbook project into EPUB3 and
>> received
>> validation errors too (but they are different). But this is another story.
>>
>>
>> > [...]
>> > Realized earlier that I had OEBPS as the base.dir and changed it to
>> book/
>>
>> Right, that's correct now.
>>
>>
>> > With that change made I'm getting epubcheck validation errors that were
>> not
>> > there before:
>>
>> Tip: You don't need to create the ZIP archive and pass it to epubcheck.
>> You
>> can start the validation process right after xsltproc wrote the
>> directories
>> without creating the ZIP archive.
>>
>> For example, if you've used foo/ as base.dir, invoke epubcheck with this
>> option after the transformation step:
>>
>> $ epubcheck foo/ -mode exp
>>
>> It is even possible to validate only parts of the EPUB (directory), also
>> with
>> the -mode option:
>>
>> mo = Media overlays
>> nav = Navigation document
>> opf = package document
>> svg = SVG content
>> xhtml = XHTML content
>>
>> The -version option specifies with EPUB version to validate (the values
>> can be
>> either 2.0 or 3.0).
>>
>>
>> > 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.
>>
>> This indeed looks strange. However, I didn't get such validation errors.
>> I've
>> used the last public stable release (1.78.1) and the snapshot from
>> docbook-
>> xsl-snapshot.tar.bz2 file, both with success.
>>
>> Do you use a customization layer?
>>
>>
>>
>> --
>> Gruß/Regards
>> Thomas Schraitle
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>>
>>
>

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

I would urge against the "default = don't work" option.
If that's what backward-compatibility would give then backward-compatibility should be lost.

"default = it works" should take precedence.


Definitely,
Richard.