I'm coming to the conclusion that the EPUB3 standard changed after the
Docbook epub3 stylesheet was created. The EPUB3 standard is based on
XHTML5, and XHTML5 does permit @width on elements. Further
evidence of the change is that in the DocBook template that converts
banned attributes to
I presume you are using the epub3 stylesheet, which is better supports
the current EPUB standard. The DocBook epub3 stylesheet imports the
xhtml5 stylesheet as its starting point. In the xhtml5 stylesheet,
banned attributes like @width in an element are supposed to be
converted to a single
Hi Philo,
So the problem which remains is that the XHTML docs from the generated
EPUB archive have the image reference looking like this:
right? Does this way of specifying the proportional width work with the
EPUB reader? So is it only a problem of validation errors reported by
the epub
Hi Mary,
Ditto what Nat said.
Thanks!
~Barton Wright
Hi Mary,
I'd be interested in your solutions to your webhelp issues. I've currently
got webhelp in beta, with HTML and PDF in production. I've come across a
number of webhelp issues and I'm not happy with this format yet.
Nat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'd suggest finding common solutions to the major issues and
contributing back to the distribution so you can avoid fixing the same
problems in different ways and having to maintain those in your own forks.
Maybe start with some discussion here and
On 9/5/14, 10:03 AM, David Cramer wrote:
Should other options for search be provided? E.g. you could replace the
javascript search with a Google site search. Believe it or not, all the
books in the API Documentation portion of this site is actually
webhelp (it's my former employer and I was
