[oXygen-user] oXygen to WordPress

[Eliot Kimber]

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" < 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
>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
>
>https://www.oxygenxml.com/mailman/listinfo/oxygen-user