Closed Ndidi closed 6 months ago
You're right, I suspect there's some final step missing. It makes the manifest file, the index and others, but somehow, it does not compress the files. If you look inside epub file, it is a simple zip!
Yeah. I I'll put the solution in a new sbt task or just link it to the existing epubTask
.
It would make sense to have it as part of the epubTask
so that running sbt epub
spits out the final epub file. You can leave the intermediate files in target
or you might consider removing them when the task completes.
I was thinking more along the lines of having a task that calls a task, as opposed to leaving users to doing it themselves..
Hmm.. That still could be considered over-engineering since it is only the epubTask
that has this issue.. Details, details. Let me get it working first before worrying about the more trivial issues..
I believe there's a reason as to why the original developer didn't zip up the EPUB files into an actual EPUB document.
In fact, it's an issue that applies to all multifile outputs this plugin produces (e.g. sbt epub
, sbt html-chunk
, etc.). I'm yet to find an acceptable method of obtaining the name of a project a plugin is applied to.
xsbt-reflect begins to answer this problem, however xsbt-reflect does not apply to a project applied to another project (which is essentially what a plugin is). In other words, xsbt-reflect returns sbt-docbook-plugin
which is useless for our purposes..
Resolved.
Not quite--if you look in the generated epub file, it includes one extra sub-directory. This means that you can't read it in ebook readers. Download Acrobat Digital Editions, for example, to test the generated files.
It's been a minute.
A final epub document is not created after running
sbt epub
, although the required files are generated.It appears to have always existed.