Hello, So I stumbled across this post from a couple of years ago: https://www.oxygenxml.com/pipermail/oxygen-user/2013-August/004754.html Basically just asking for a feature to update a WordPress blog and said request being forwarded along. I've got two questions: 1) Did it become a feature? 2) If not, now that WordPress supplies an optional JSON based REST API, could the request be revisited since it ought to make it easier to make the two things play nicely together? WordPress API documentation: http://v2.wp-api.org/ I've only looked at it briefly, but it's REST so it can't be that hard, not as far as communicating with the server is concerned, at any rate. I've done a few client-side interaction things like this at times; mainly grabbing Bitcoin and/or currency live data and playing with the Twitter API so from my perspective the worst case scenario is making the right HTML template to play nicely at the other end and adding a few Python scripts (well, of course, by now everyone saw *that* language preference coming). Still, there's a lot to be said for "point and click" if it just works. Although the Github repositories also include command line tools and a console for the thing, so chances are integration could be reduced to calling the relevant commands to do whatever. The rough edges at the moment appear to be limited to generating the OAuth credentials, but that's not a huge chore for most WordPress admins. Regards, Ben -- Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes Writer, Systems Administrator, Trainer, ICT Consultant GPGME Python 3 API Maintainer, GNU Privacy Guard https://www.gnupg.org/ Encrypted email preferred, primary OpenPGP/GPG key: 0x321E4E2373590E5D OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D OpenPGP/GPG key transition: http://www.adversary.org/keyswitch.txt.asc
Hi Ben, We have not (yet) implemented such a "Publish To WordPress" feature. And also right now this is not on our todo list. Oxygen has lots of API so hypothetically speaking an Oxygen plugin could be built for this. Or you can just publish to XHTML and then upload that XHTML content to the WordPress web site. A problem would be with referenced images. Usually when I blog, I blog in DITA and I embed the images in the XHTML content using base 64 encoding, thus the XHTML which I paste in the uploaded blog content contains all the information inside it. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/5/2016 12:33 AM, Ben McGinnes wrote:
Hello, So I stumbled across this post from a couple of years ago:
https://www.oxygenxml.com/pipermail/oxygen-user/2013-August/004754.html
Basically just asking for a feature to update a WordPress blog and said request being forwarded along. I've got two questions:
1) Did it become a feature?
2) If not, now that WordPress supplies an optional JSON based REST API, could the request be revisited since it ought to make it easier to make the two things play nicely together?
WordPress API documentation:
I've only looked at it briefly, but it's REST so it can't be that hard, not as far as communicating with the server is concerned, at any rate. I've done a few client-side interaction things like this at times; mainly grabbing Bitcoin and/or currency live data and playing with the Twitter API so from my perspective the worst case scenario is making the right HTML template to play nicely at the other end and adding a few Python scripts (well, of course, by now everyone saw *that* language preference coming). Still, there's a lot to be said for "point and click" if it just works.
Although the Github repositories also include command line tools and a console for the thing, so chances are integration could be reduced to calling the relevant commands to do whatever. The rough edges at the moment appear to be limited to generating the OAuth credentials, but that's not a huge chore for most WordPress admins.
Regards, Ben
On 5/01/2016 6:52 pm, Oxygen XML Editor Support (Radu Coravu) wrote:
Hi Ben,
We have not (yet) implemented such a "Publish To WordPress" feature.
Cool.
And also right now this is not on our todo list.
Fair enough.
Oxygen has lots of API so hypothetically speaking an Oxygen plugin could be built for this. Or you can just publish to XHTML and then upload that XHTML content to the WordPress web site.
Yeah, I suspect I'll opt for this or a variant of it. Probably something along the lines of DITA to [X]HTML 5 (by file rather than map) and then run a command line script to do the rest (or call via the external applications feature).
A problem would be with referenced images. Usually when I blog, I blog in DITA and I embed the images in the XHTML content using base 64 encoding, thus the XHTML which I paste in the uploaded blog content contains all the information inside it.
I did something similar for a userstyles.org theme (i.e. just a CSS file) for the ICCF website (iccf.com). I've also got scripts that let you feed a CSS file with image references in at one end and get a rewritten CSS with base64 encoded image data in them out the other. They're over on Github somewhere, I can't remember which repo off the top of my head. The only thing is my WordPress site is sitting on an AWS EC2 instance and is configured to move all the media files to an S3 bucket and then rewrite the references to load from there (to improve loading and response times as well as reduce traffic costs). Still that can be side-stepped entirely by uploading straight to an S3 bucket and setting the references directly in the HTML (or it might be able to use the current plugin method on the blog via the API, I haven't peered that deeply under the hood yet). I think for now, though, I'll focus on the problem that is really bugging me: how to get DITA (specifically D4P) to ePub 3.0 with only a minor amount of post build editing (I expect to have to check and/or mess with the metadata after generation, but not every file). Though the webhelp transformation looks like it's about 90% of the way there, it just needs to generate an NCX file and manifest from that context XML file and a TOC Nav file and spine from the index file, then piece those together with the metadata for the OPF and bundle the whole thing up and it's done, more or less. Regards, Ben
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. I'm not sure if there would be an automated convertor which could convert between EPUB 2.0 and EPUB 3.0. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/6/2016 8:20 PM, Ben McGinnes wrote:
On 5/01/2016 6:52 pm, Oxygen XML Editor Support (Radu Coravu) wrote:
Hi Ben,
We have not (yet) implemented such a "Publish To WordPress" feature.
Cool.
And also right now this is not on our todo list.
Fair enough.
Oxygen has lots of API so hypothetically speaking an Oxygen plugin could be built for this. Or you can just publish to XHTML and then upload that XHTML content to the WordPress web site.
Yeah, I suspect I'll opt for this or a variant of it. Probably something along the lines of DITA to [X]HTML 5 (by file rather than map) and then run a command line script to do the rest (or call via the external applications feature).
A problem would be with referenced images. Usually when I blog, I blog in DITA and I embed the images in the XHTML content using base 64 encoding, thus the XHTML which I paste in the uploaded blog content contains all the information inside it.
I did something similar for a userstyles.org theme (i.e. just a CSS file) for the ICCF website (iccf.com). I've also got scripts that let you feed a CSS file with image references in at one end and get a rewritten CSS with base64 encoded image data in them out the other. They're over on Github somewhere, I can't remember which repo off the top of my head.
The only thing is my WordPress site is sitting on an AWS EC2 instance and is configured to move all the media files to an S3 bucket and then rewrite the references to load from there (to improve loading and response times as well as reduce traffic costs). Still that can be side-stepped entirely by uploading straight to an S3 bucket and setting the references directly in the HTML (or it might be able to use the current plugin method on the blog via the API, I haven't peered that deeply under the hood yet).
I think for now, though, I'll focus on the problem that is really bugging me: how to get DITA (specifically D4P) to ePub 3.0 with only a minor amount of post build editing (I expect to have to check and/or mess with the metadata after generation, but not every file). Though the webhelp transformation looks like it's about 90% of the way there, it just needs to generate an NCX file and manifest from that context XML file and a TOC Nav file and spine from the index file, then piece those together with the metadata for the OPF and bundle the whole thing up and it's done, more or less.
Regards, Ben
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
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
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
On 10/01/2016 12:39 am, Eliot Kimber wrote:
The current DITA for Publishers EPUB transform can produce EPUB3, EPUB2/3, or EPUB2.
Really? Because every time I've tried it I get errors like this and I am running the latest from github master. This installation of oXygen, as Radu and his colleagues already know, is significantly customised, there's a pristine install in an adjacent directory just in case. Amongst those customisations is all the most recent D4P bits and is accompanied with a careful pruning of the sourceforge old versions that ship with oXygen. In the case of the epub plugins this meant moving the sf epub and kindle plugins out and just renaming the github directories. It works fine for generating a straight "epub" transtype (epub 2.0.1 output), but change that to epub3 and failure comes a-calling: System ID: /Users/ben/Documents/Mine/Politics/REDACTED_PATH/REDACTED-map.ditamap Scenario: DITA Map EPUB2 Input file: /Users/ben/Documents/Mine/Politics/REDACTED_PATH/REDACTED-map.ditamap Engine name: DITA-OT Severity: fatal Description: [DOTA001F] "epub3" is not a recognized transformation type. Supported transformation types are d4p-html5, d4pjournals, docbook, eclipsecontent, eclipsehelp, epub, graphviz, html2, htmlhelp, indesign, javahelp, json, kindle, legacypdf, odt, pdf, pdf-css, pdf2, qa, reveal, rss, subjectscheme2navmap, tocjs, troff, webhelp, webhelp-feedback, webhelp-feedback-mobile, webhelp-mobile, word2dita, wordrtf, xhtml. URL: http://www.oxygenxml.com/DITA-messages.html#msgs__DOTA001F Which is the same as trying it in the d4p-html5 plugin directly: /usr/local/oXygenXML/stable/oxygenOSX-17.1/frameworks/dita/DITA-OT/build.xml:36: [DOTA001F][FATAL] "epub3" is not a recognized transformation type. Supported transformation types are d4p-html5, d4pjournals, docbook, eclipsecontent, eclipsehelp, epub, graphviz, html2, htmlhelp, indesign, javahelp, json, kindle, legacypdf, odt, pdf, pdf-css, pdf2, qa, reveal, rss, subjectscheme2navmap, tocjs, troff, webhelp, webhelp-feedback, webhelp-feedback-mobile, webhelp-mobile, word2dita, wordrtf, xhtml. So what have I missed? Regards, Ben
On 10/01/2016 8:21 am, Ben McGinnes wrote:
On 10/01/2016 12:39 am, Eliot Kimber wrote:
The current DITA for Publishers EPUB transform can produce EPUB3, EPUB2/3, or EPUB2.
Really? Because every time I've tried it I get errors like this and I
Erm, nevermind ... apparently what I was missing was that I *not* change the transtype and leave it as epub, but do change the git branch in the plugin directory from master to epub3. Plus epubcheck wants xhtml+xml files named as .xhtml or it whinges, so changing that output extension is advisable too. Regards, Ben
Please report any failure to conform to the EPUB3 spec as an issue on GitHub. I haven't had the bandwidth to test the output against epubcheck in the last 6 months or so (the last major update was for Harper-Collins, who funded the EPUB3 work and seem to be happy with the output being produced). Steven Calderwood (now at RSI but previously at Human Kinetics) did a lot of work to sort out epubcheck details but epubcheck is a moving target. Cheers, E. ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com On 1/9/16, 5:16 PM, "Ben McGinnes" <ben@adversary.org> wrote:
On 10/01/2016 8:21 am, Ben McGinnes wrote:
On 10/01/2016 12:39 am, Eliot Kimber wrote:
The current DITA for Publishers EPUB transform can produce EPUB3, EPUB2/3, or EPUB2.
Really? Because every time I've tried it I get errors like this and I
Erm, nevermind ... apparently what I was missing was that I *not* change the transtype and leave it as epub, but do change the git branch in the plugin directory from master to epub3. Plus epubcheck wants xhtml+xml files named as .xhtml or it whinges, so changing that output extension is advisable too.
Regards, Ben
On 11/01/2016 8:34 am, Eliot Kimber wrote:
Please report any failure to conform to the EPUB3 spec as an issue on GitHub.
It looks to be mostly fine. I got about half a dozen errors, but three of those were produced by extra things I'd added to either the oXygen webhelp css directory or the DITA-OT XHTML CSS directory, probably the latter. That can be fixed by simply removing the added files (which I did after I appended theapprox. 250 lines of CSS previously patched to the D4P-HTML5 transformation to commonltr.css and commonrtl.css (and it does indeed make small capitals behave properly with bold and underline or strike through and all the rest. The other three errors were .html vs. .xhtml extension complaints. In those cases it was due to having three parts with no corresponding .dita file, just navtitles and for the epub the XHTML is produced . Those topic files default to having a .html extension, but can no doubt be avoided entirely by making them actual .dita files to transform with all the rest.
I haven't had the bandwidth to test the output against epubcheck in the last 6 months or so (the last major update was for Harper-Collins, who funded the EPUB3 work and seem to be happy with the output being produced).
As long as they remain pedantic about every file it ought to be fine from what I can see.
Steven Calderwood (now at RSI but previously at Human Kinetics) did a lot of work to sort out epubcheck details but epubcheck is a moving target.
And it still does. I'll add my explicit dividers for each part of my little test book and confirm that. Which means the only thing left over which I tend to do manually is the metadata. In some cases this is because the automatic method doesn't seem quite right, but mainly it's because I figure it's worth being fairly pedantic about and will eventually have a large portion of it being much the same across projects anyway. The one bit of it that doesn't work at all by default in oXygen and is the same in the Docbook template is the meta element for dcterms:modified being set to the timestamp for the local timezone, but fudged to have the Z on the end appended. After that the only build error in oXygen, but not an error in a subsequent epubcheck is not including a title on the d4pcover page. Obviously that's expected. Since writing the above I made the relevant adjustments so there would be no topic generated HTML files and got rid of the extra CSS files (leaving only my modified ones in org.dita.xhtml/resources/) and it builds with no errors, passes the epubcheck with no errors or warnings and only has the same build warning mentioned as expects. The only changes I make post buid are to pasts in a previously prepared block of metadata and change the filename. At which point it's ready for release (unless it's a draft in which case it's ready for review). Regards, Ben
participants (3)
-
Ben McGinnes -
Eliot Kimber -
Oxygen XML Editor Support (Radu Coravu)