Detecting language please wait for.......
Has anyone processed XPP jobs into an epub where the epub output needs to very closely match the formatting of the XPP? Some headers and spacing/line breaks in the epub don't match the division and colors are applied.
The xpp2epub_DEMO.pl tool creates epub2 output, can this be set to produce epub3 output?
Left is the XPP division, Right is the epub2 output...
The delivered demo is just a generic example of how an epub export could be made. You will have to tune it to make anything useful out of it.
The epub output can certainly set up to match your example…
Always good to activate some extra brain cells.Here is some more food for thought:
The project I did for Chris predated the divxml utility. But the input data was xml, so we exported it back from…
The epub output can certainly set up to match your example XPP output. The epub formatting is CSS based, so there is nothing in your sample output that can't be matched in your epub output.
And in the divxml output (the xpp utility used by the xpp2epub_DEMO.pl tool) there is more than enough information available on how things are presented on the XPP PDF output.
Some years ago (before the xpp2epub_DEMO or the underlying divxml tool was available) I did a project for Letterpart on a whole series of (legal commentary?) books. Maybe Chris still has some samples on how well the epub matched the pdf output.
At first glance I can't see any problem (based on the limited sample you have shown) to make things match.
Thanks for the info Bart...now I'm off to the divxml documentation.
Hi JohnWe produced 3 different things:
1. A print PDF (as normal) - this had footnotes at the foot of each relevant page done with conventional item formats etc.
2. An "ePDF" which had links from the contents, tables and Index etc to the paragraph numbers and looked identical to the print PDF in formatting etc. (indeed it was made without recomposing - just using different print options).
3. An ePUB - the ePUB was not an "exact" replica of the PDF (because that was not what was required) - moreover it was a fully responsive PDF that appeared correctly on screen whether that be full width or on a mobile. The design was similar in style but more without some of the "XPP specific" features. The footnotes were moved to the end of the Chapter and links to and from were inserted.
Ok, now I have visual proof it can be done...just need to activate some extra brain cells with Clif.
The project I did for Chris predated the divxml utility. But the input data was xml, so we exported it back from xpp, converted it to html and chopped it up into usable epub chapters and added the necessary extra files epub needs. 2 conditions here:- input in xpp needs to be xml- styles must be used in a consistent way and are more or less hardwired into the tool you build.
You can also take the route that the xpp2epub_DEMO tool is using and that transforming the divxml output into usable epub files. Compared to the previous method this gives you 2 advantages:- input does not need to be xml. divxml will always output xml files.- style info does not need to be hardwired into the tool. The divxml output will gives you all the presentation info you need.Disadvantage is that the divxml output is rather complicated and centered around presentation of lines of text. It will take you a while to completely understand the divxml format (a complication you do not have when taking route 1 as you know already what is in the styles definition for each xml tag)Good luck!