More conventional structure of export process

[pank]

Hi,

I think it would be a lot nicer to use ox-epub if it worked more like a normal exporter.

Currently, it seems to depend on ox-publish which is not always the quickest way. For instance, it seems a lot finishing is tied into org-epub-publish-finish. But if I run a normal export via C-c C-e I wouldn't get that. So that might be better to wrap many of these things into org-epub-export-{to,as}-epub functions that wraps everything up. The functions in ox-odt will already something similar, as they also need to wrap up images and external styles files and manifests into a single zipped file.

That would also allow you to include a :menu-entry into your derived backend, hooking into C-c C-e.

I don't know if this goes against your initial intention ox-epub.el.

[ofosos]

I think it's possible to implement, the only downside being, we'd have to go back and regenerate the content.opf and possibly the manifest, when exporting single html files. There'd need to be some dependency logic to do this, in general it seems a bit cleaner to do this in a second pass.

The difference between more conventional exporters and this is, that we're generating one compound epub file out of possibly many documents. I don't think this is necessarily a bad idea, but might have to be rethought.

Other publishing systems do this with an include process (have a toplevel org file and then include the constituent parts) and publish that. I wasn't aware of the #INCLUDE directive in org mode, when I wrote this.

The nice thing about bundling multiple .org files into a single epub is the ability to order the generated .html files at will and to do something like

1. book cover (source: Image)
2. preface (souce: an org file)
3. table of contents (source: generated)
4. first chapter (source: an org file) ....
5. Index (source: generated)

I.e. you can interleave generated and manual content by means of the spine. While hypertext maintains a kind of non-linear structure, the spine will order the structure into an entirely linear reading experience.

[ofosos]

org-odt seems to be a good template to do this. This would uncomplicate several things. Specifically the process of fetching the headlines for the out of band TOC.

[ofosos]

I think the best argument to support this, is the support for narrowing in the source buffer.

[pank]

It makes testing easier as well. It makes it easier for users like me who either use the export dispatcher or make. I only use ox-publish for my web site.

[ofosos]

Any items remaining in this issue from your perspective?

[pank]

I haven't read all of the code, but feel free to close this.

You could add a keyboard shortcut to also open the file after it has been generated.

[ofosos]

Option added.