[oXygen-user] oXygen to WordPress
Sat Jan 9 07:39:31 CST 2016
The current DITA for Publishers EPUB transform can produce EPUB3, EPUB2/3,
Eliot Kimber, Owner
On 1/8/16, 8:03 PM, "Ben McGinnes" < on
behalf of > 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
>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.
>oXygen-user mailing list
More information about the oXygen-user