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" <[email protected] on behalf of [email protected]> 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 >[email protected] >https://www.oxygenxml.com/mailman/listinfo/oxygen-user _______________________________________________ oXygen-user mailing list [email protected] https://www.oxygenxml.com/mailman/listinfo/oxygen-user
