-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show how to generate EPUB and MOBI #13
Comments
That's a great request. Last I checked I believe the epub3 backend should generate an epub first then use that as a basis for the conversion to mobi. I'll look into adding a mobi specific example. |
Just curious - what's the difference between the generated |
index-kf8.epub is an intermediary file for generating .mobi. Kindlegen requires a few changes to the EPUB3 in order to properly produce a .mobi file and this file has those changes. Otherwise, it's just a temp file for debugging (so you can see what we sent to kindlegen). |
kf8 isn't a separate backend. Instead, you have to run Asciidoctor twice using a different value for the
To handle this case, I recommend having a separate Asciidoctor task rather than a collection of backends in a single Asciidoctor task. However, it might be nice if the Gradle plugin detected the |
@mojavelinux I was just looking into putting a sample together. The sample is just trying to do kf8 for now. Running with the asciidoctor-epub3 (ruby) it seems to work. However, Gradle seems I get the following error:
|
When running in the AsciidoctorJ environment, it's necessary to specify the path to We're not allowed to bundle
Note that the path is to the kindlegen binary itself. |
@mojavelinux Thanks for the tip. I'm curious why it works with Ruby? Is it different rules? |
kindlegen isn't really a gem. It's just using Since we never run I've been talking to Matt Raible about probably just bringing in the code that downloads and extracts Kindlegen into Asciidoctor EPUB3 so it works consistently everywhere. |
Btw, here's the kindlegen download script that currently gets run when you execute /~https://github.com/tdtds/kindlegen/blob/master/ext/kindlegen/extconf.rb |
Thanks for the reply. Does that mean I should probably hold off on putting the sample together since this will be improved? Or is it far enough out that putting something together would be valuable? |
I would just start with a comment in the build.gradle file. That gives a hint to people stopping by and documents future work. I would say that to generate a KF8/MOBI file that you need to do two things:
Also note that if you want to generate both the EPUB3 and the KF8/MOBI, you need two invocations of Asciidoctor using the epub3 backend. That at least lays the groundwork. |
You might also note that there will be a *-kf8.epub3 generated in the output directory. That is a temporary file and should only be used for debugging. |
Eventually that tmp file will get nuked unless the debug flag is enabled. |
Is it possible to have a |
Both are possible. I'll try and put something together tonight.
This is possible. I don't have time at the moment, but I think I can whip something up tonight that does it for you.
You could get around this by including a gradle file with the common configuration, but I think the multiple tasks is better. |
I know there are examples of this floating around. Here are some: Here's a rough snippet to give you an idea: apply plugin: 'org.asciidoctor.convert'
import org.asciidoctor.gradle.AsciidoctorTask
tasks.withType(AsciidoctorTask) { task ->
sourceDir "$sources"
outputDir "$output"
sources {
include 'index.adoc'
}
attributes = 'source-highlighter': 'coderay',
experimental: true,
toc: 'right',
idprefix: '',
idseparator: '-'
}
task generateHtml(type: AsciidoctorTask, description: 'Generates single page HTML') {
backends 'html5'
}
task generatePdf(type: AsciidoctorTask, description: 'Generates PDF') {
backends 'pdf'
}
task generateEpub(type: AsciidoctorTask, description: 'Generates EPUB3') {
backends 'epub3'
} |
Thanks @mojavelinux. Here's what I came up with:
The major issue I've found is that the 'epub' task fails, so 'mobi' never gets kicked off. The index.epub file seems to be generated OK, so I'm not sure why it fails.
It seems this is an open issue: asciidoctor/asciidoctor-epub3#25 It might be possible to set a KINDLEGEN environment variable using something like the following, but I'm not sure how to make a task dependent on two types. http://stackoverflow.com/questions/22605947/how-do-set-environment-variable-in-gradle-via-task I'd be nice to consolidate the attributes too. The following seems to accomplish this:
|
To get this to run and create HTML5, PDF, EPUB and MOBI formats, I added an 'all' task:
Then I created a
|
I didn't get any free time last night to complete the sample. Seems like @mraible beat me to getting it working. I updated the sample to automatically download kindlegen (only supports OSX and Linux at the moment). I also set the gradlew script to export the KINDLEGEN environment variable to the location that the Gradle build will unzip the kindlegen script. However, I'm getting an error that is posted below. Occasionally it appears to work, but not sure why. Any ideas as to what is wrong?
|
This likely has something to do with these lines and how we are calling the external command. Perhaps in the JRuby environment popen2e isn't working or isn't always working, or is returning some funky result. It's probably best just to put a try/catch around it and if it fails to return a happy value we just move on because clearly it's invoking kindlegen. It might also have to do with JRuby 1.7. I wonder if the same problem happens if you use JRuby 9000 instead. I know they fixed some things with native process threads, so maybe this is that issue. |
I think this happens when an entry gets into the spine collection that isn't the type it expects. It's obviously assuming too much at the moment, but that's the only possible explanation I can think of. |
Actually, I'm starting think that something is trying to convert the document after its already converted because this message is coming after the file is written. Hmm.... |
Yep, that's definitely what is happening. For some reason we are going back into the converter again at the very end and I have no idea what state things are in at that point. |
I have a suspicion that what a converter implements its own write method (as is the case with the EPUB3 converter), AsciidoctorJ is calling the write method twice. |
Aha! The problem is that you aren't specifying a source document, so it's attempting to convert all the AsciiDoc files. Asciidoctor EPUB3 can only be run on a spine document, so as a result you are getting wild results.
We definitely need to make it so that Asciidoctor EPUB3 doesn't choke on an arbitrary AsciiDoc document. But for now, that's the rule. |
Btw, if you want to test against local gems, here are the steps. First, setup a gemset for RVM (which of course, you need to have)
Then, install the gems you need:
Finally, set the following in your Asciidoctor task.
What that does is make JRuby use gems installed on your system instead of the gems in the AsciidoctorJ jar. This allows you to modify the Ruby files to add debug statements and such. You can also debug the files if you use something like RubyMine. |
@mojavelinux Thanks for the tip. Two follow up questions:
|
We're talking about two different repositories. This was a problem specific to the JHipster book, which didn't have the leading
I think the problem you are getting is different. Though, I bet it still has to do with the structure of the document. I'll take a closer look. |
...so I checked and the problem is that the example-manual.adoc in the asciidoc-to-epub3-example project doesn't conform to the structure that Asciidoctor EPUB3 currently requires. I want to emphasize that I do want to remove this restriction, but if we are talking about what is already released, then we must adhere to it to avoid errors. /~https://github.com/asciidoctor/asciidoctor-epub3#declaring-the-spine |
We have two separate things going on here:
I don't really understand the problem with (2) and I'm not able to reproduce it (yet). I just wanted to make it clear that (1) and (2) are separate issues as far as I can tell. |
Btw, love the automatic download of Kindlegen! I'm trying out your sample now. |
Aha! I bet my suspicion about Posix spawn in JRuby 1.7 is right.
As far as I understand it this was one of the main things fixed in JRuby 9000. So in this subproject, we should use JRuby 9000. |
Ah, so that's how you do it! Good thinking. Yet another area that the Gradle docs really let us down (unless my Googling is getting weak). |
I'm happy to confirm that changing the following from:
To:
Does indeed fix any failure issues I had with EPUB and MOBI. Here's my
And here's the output from running it after the change.
|
Fantastic news! Thanks for following up. Having the kf8/mobi generation in the Gradle examples will definitely help avoid this stumbling block in the future. I've also marked it as a priority to address the failure when running the epub3 backend on an arbitrary AsciiDoc structure (asciidoctor/asciidoctor-epub3#25). |
Use github fork badge
@rwinch I think we should move forward with merging your branch with the Kindlegen download tasks. Want to send a pull request? I was thinking that the Kindlegen download would probably make a pretty kick ass plugin, since we can't otherwise distribute Kindlegen. The task might be something like "kindlegen-install" and perhaps "kindlegen-run". wdyt? |
Thanks for this thread. I now have a version of @mraible's My folder structure is:
Here is the HTML task from
Alas, when I run
This is interesting because the real path is:
When I copy the |
I've been experimenting a bit more. It seems the
If I then run in quiet mode:
The two |
Spaces in file names are rarely supported cross platform and should be avoided at all costs. I think it's generally accepted that having a space in file name is an input error. There are numerous components that could be mangling it, from Gradle to JRuby or something in between. |
Despite my rant, this appears to have been fixed in the upcoming release of the Asciidoctor Gradle plugin. You can see the change here: asciidoctor/asciidoctor-gradle-plugin@25142d4#diff-467e6edfd5f5943cc0fdf8e11457f034L586 (I still think spaces in file names are a bad idea, but at least the case you reported has been solved). |
Thanks, Dan. I agree and wouldn't put spaces in the actual file names myself, but it is quite normal for folder names to have spaces in them (I'm thinking of the Windows 'My Documents' folder, for example). I had tried escaping the spaces in folder names, but it didn't work. I'll pull the latest version of AD-gradle and report back. |
How do I force it to use this version of AS-gradle? Or do I just need to wait for the new release to go live? |
To clarify, this didn't work because the Gradle plugin was previously removing spaces explicitly.
This should really be covered in the README of the Gradle plugin. However, it is not currently. Clone the project:
Switch to the project
Install the project to your local Maven repository
Configure the dependency in your build.gradle
|
Thanks! I can confirm that worked. Much appreciated. |
Great news! |
asciidoctor/asciidoctor-gradle-examples#13 Former-commit-id: f4bd4f59c93761c7f899679986c06cc43ca60787
asciidoctor/asciidoctor-gradle-examples#13 (comment) Former-commit-id: 0f776369c01d4023d56f45905e70ab4ab79ba859
There is an example project that shows how to generate an EPUB document. The documentation for asciidoctor-epub3 says it's also capable of generating a MOBI document.
/~https://github.com/asciidoctor/asciidoctor-epub3
Can you please document how to generate an EPUB and a MOBI document in the same project? Here's what I tried. A build/asciidoctor/kf8 directory is created, but there's nothing in it.
The text was updated successfully, but these errors were encountered: