The current DITA for Publishers EPUB transform can produce EPUB3, EPUB2/3, or EPUB2. Cheers, E. ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com On 1/8/16, 8:03 PM, "Ben McGinnes" <oxygen-user-bounces@oxygenxml.com on behalf of ben@adversary.org> wrote:
On 7/01/2016 8:30 pm, Oxygen XML Editor Support (Radu Coravu) wrote:
Hi Ben,
I'm not sure about how best to approach the creation of EPUB 3.0 from DITA. If I were you I would incline more towards modifying the existing DITA to EPUB 2.0 transformation.
That's kind of the route I'm heading down, using the d4p-html5 plugin (which seems to have a plain webhelp option too and I'm assuming that's the initial foundation of the current DITA map to WebHelp transformation you made). Then run it at least twice, once to generate HTML 5 output and directory structure (I just need to remove the search box from being visible); and once to generate the NCX and ePub 2 style navigation tools. The manifest can basically be done with a little shell or other scripting, the spine ought to be achievable from pillaging the index and making the toc.xhtml navigation can use the same data. The guide section isn't really used much any more, so for backwards compatibility you just point it at either or both of the two toc files.
Automating or scripting most of that, once I have all the pieces, won't be too much of a proplem, but my grasp of XSLTs is currently best described as crap. So producing a drop-in solution for everyone would need a little extra care and attention. From my POV, though, I'll be very happy if I can get ePub 3 production to the same point that ePub 2 is now. Which is basically generating entirely without errors and only requiring me to open it up and paste in more thorough metadata at the top of the OPF file.
One feature the webhelp transformation has which is superior to the d4p-html5 plugin is copying any CSS file in the resource/css/ directory into the output directories or output file. Very useful if you have more than one stylesheet for different parts of the document. Whereas currently D4P only allows one CSS file. Although the even easier method is to append the most generic updates to the commonltr.css and commonrtl.css files in both the oXygen custom webhelp plugin and the ones in the main DITA-OT default paths.
Since most of my additions were for generic things like small capitals that I'd want on more than one project, so patching those files ought to be the sensible solution. Well, relatively sensible. I do need to remember to do it with each release.
I'm not sure if there would be an automated convertor which could convert between EPUB 2.0 and EPUB 3.0.
No reliable ones (yet). Not that I've seen at any rate. It shouldn't matter too much anyway. All I need is to be able to build an XML conforming HTML 5 thing like d4p-html5 does without the navigational links (easy enough) and without the search box appearing on the page (this is proving a bit more difficult to isolate). Removing the navigation and the search function are essentially because the ereader is supposed to do that (my Kobo Aura H2O certainly can). Then it's just a matter of scripting the generation of the rest and tying it all together.
Oh, yeah, going by way of DocBook tends towards the inconsistent or filled with errors. Especially with the little thing I'm using for my first thorough test. It isn't big, but it has typographically strict verse requirements and a few other things, so I get to test the verse and stanza elements as well as regular text. So it's fine for most prose, but I'd hate to have to try publishing something like the Norton Anthology of Poetry (any edition, the bloody thing is enormous) in ePub 2.0.
That is another reason for wanting to push into ePub 3.0, because far too many of the ereader software packages I tested on so far can't handle that type of text structure. Several of them can't even handle multiple creator elements; some pick the first author while others pick the second.
In fact, some of them don't even like setting a proper ISBN as the unique identifier, which I thought was a bit too special. After all, it's not like the software could claim that the ISBN belonged to another entity or company or that it wasn't a legitimate ISBN. Though I don't think there are many software packages that actually bother to calculate an ISBN's checksum.
Regards, Ben
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user