Scribus workflow for PDF and ePub Output

[Jim]

Generally in self-publishing authors are expected to supply a PDF for the print version of their book and an ePub file for the ebook version of their book.

Since Scribus can not be used to produce an ePub file, I would like to know how authors here handle that part of their workflow.

For my part I am creating a photobook. While I do have a copy of Adobe Indesign and could use that, it seems to me that by using Scribus I can be more productive more quickly (the software just makes sense to me).

But - the single stumbling block is that Scribus can not produce an epub file.

I would love to hear how others handle this shortcoming.

Thanks, Jim.

[dragonfly]

First, I am just a user and developer (on Ubuntu 16.04) bouncing around some ideas for integrating Scribus in a project publication toolchain. Reading the Adobe discussion forums today I still see users asking for a Linux port but that is not forthcoming.

There are some threads in this Scribus forum discussing ePub (just search) and here is a recent one.

http://forums.scribus.net/index.php/topic,2508.msg13859.html#msg13859

My personal approach is to go back a few steps in the workflow and provide content which can be piped to Scribus (for quality printing), and/or to the web. This workflow works for me.

Another recent (rather long) thread discusses the example of compiling and publishing music books - http://forums.scribus.net/index.php/topic,3042.0.html.

If you are game for experimenting read here. Pandoc.

https://pandoc.org/epub.html

I am using Atom as my open source front end tool which through added package Markdown Preview Enhanced can pre-process markdown (including images) and generate content as assets for import by Scribus, and importantly also export to ePub all within the same workflow.

[Jim]

Hi Dragonfly,

Addressing each of your points. First that Scribus is available on Linux is a plus for me. I still use Windows 7 mainly because that's where I've got the CS4 suite installed. I agree with you about there not being a Linux port of the Adobe suite of applications.

I did so some forum searching and came across a couple of threads (including the one you cite) - one of which referenced Pandoc - which I am now investigating. At first glance, it might appear that Pandoc would be a replacement for Scribus since you'd be creating your source as markdown and then using Pandoc to create the appropriate output file. I really can't say one way or the other (about bypassing Scribus) at this stage since I have zero experience with Pandoc.

Thanks for the music book thread link - I'll have to read through that one.

I used to have Atom installed but it was by far the slowest text editor on my machine and, unlike my other editors, would bog down with very large files. I wound up uninstalling it. The Pandocs Extras page at https://github.com/jgm/pandoc/wiki/Pandoc-Extras does have info about packages for other editors. 

The last bit of your response about "...generate content as assets for import by Scribus, and importantly also export to ePub all within the same workflow."  may be the solution I go with - although it would require duplication since the images I'd be using for the print version of the book would be of one size and the images for the epub version would be of a smaller size.

Thanks for your response.  Hopefully some other folks with offer some different options on this challenging issue.

[dragonfly]

At first glance, it might appear that Pandoc would be a replacement for Scribus since you'd be creating your source as markdown and then using Pandoc to create the appropriate output file.

I have learned that Scribus is an important stage for printed works because of its print colour profile management and being able to match printers' needs.

But Pandoc as a pre-processor stage can route content to ePub and Scribus.
It can also create presentations such as photo galleries.

I have had no hangups with Atom (even heavily configured with packages) and I would hazard a guess that memory available might be a factor in performance  (large files bogging down). The advice I gave to another user was to preview small chunks of the end document.

Scribus can also knit together multiple *.sla files. There is a thread on that topic.

[Jim]

Hi Dragonfly,

It took a while to read but your commentary in the post at http://forums.scribus.net/index.php/topic,3042.0.html was excellent.

One thing. I installed Pandocs and tried running a conversion from ODT to HTML. The only items it recognized were bold, italics, Hn tags, paragraphs and lists. Styling, fonts, underlines, and alignments were lost in the translation to HTML. Did not try other content types. Nor have I  tried a conversion of ODT to PDF.  Perhaps coding the source in markdown provides a fuller suite of functionality. The thing is that I would rather not have to maintain two versions of my book: one for Scribus-PDF and another that would be used to produce an ePub look-alike.

I may give Calibre a try at this as I've used it before to convert back and forth between PDFs and ebook formats.

I really wanted to be able to fully produce my book using only Scribus but it appears that such a thing won't be possible.

[a.l.e]

dragonfly is  right: the best solution is to use the material done outside of scribus for creating your ebook.

sigil is a good (even if a bit raw) tool for creating epubs.

there is an experimental plugin  for creating epubs from scribus (i'm the author...) and it might alreaady be good enough for you.
the problem: you have to compile scribus + the plugin on your machine.
(btw, the goald of that the is not to produce an epub ready for distribution, but to produce something that can be further tweaked in sigil to be a good epub, without losing the work you already did in scribus... and yes, sometimes we do more than just layout in scribus).
sadly, i have no ETA for the plugin, sorry.

[dragonfly]

I found this option .. Scribus *.sla to XHTML
https://wiki.scribus.net/canvas/Scribus_xhtml_using_Scripter
but I have not had an opportunity yet to experiment with it
to pipe xhtml into Sigil. But I say again that Markdown Preview Enhanced in Atom
allows eBook output from Preview Window (right click) or indeed custom output using Pandoc.

There should be no need to maintain two different repositories and workflows for output to Scribus and ePub (and optionally presentations and websites). The content remains common, the outline engines differ. Think of Scribus as able to work in two modes:
(a) Self contained content editor plus layout engine plus scripter (import your content and apply styles)
(b) Layout engine only in a toolchain (push your content into Scribus DOM using scripting). Here we drive Scribus from say Atom via Scribus command line option.

There is the matter of extracting styles from legacy documents (*.odt) but that is work in progress. Remember that since markdown preview is in fact HTML you can embed HTML tags (such as div, style)  inside markdown to add styles.

For my own purposes I wrap markdown text and images blocks with <div></div> tags as pseudo textframes and imageframes and renderframes to introduce fonts, css to be piped into Scribus.

In Atom I create a library of style snippets so that styles can be easily added into markdown source pages.

[a.l.e]

hi dragonfly,

do you know some c++?
with all the energy you are putting into this, i would welcome it, if you could join me in the efforts to create a clean exporter that works from inside scribus...

my next goal is to finish the table of contents plugin, but then it will be time for getting back to the epub export...

[dragonfly]

@i.l.e

I appreciate your invitation but I'm afraid that I'm not at all experienced in C++.
I tend to knock together tools into mashups.
I do have Qt5 installed on Ubuntu and I see that and PyQt as a good IDE for further developing Scribus.

My interest in Scribus continues as a user/developer but I see it it as a means of rapidly generating dynamically changing variations of documents from markdown repositories and database.  Fast turnaround of documents is important in my project I am developing so this leads to trialling automation scripts.

For Scribus TOC I would suggest a workflow to integrate with Pandoc which can generate TOC.  Pandoc has an argument toc.

https://shd101wyy.github.io/markdown-preview-enhanced/#/pandoc-pdf?id=table-of-contents

https://github.com/jgm/pandoc/wiki/Pandoc-Tricks

Also see
Local style in markdown-preview-enhanced

https://shd101wyy.github.io/markdown-preview-enhanced/#/customize-css

In short I think that a Scribus TOC plugin overlaps Pandoc TOC and is only relevant to users who only use Scribus as their editor/layout DTP tool.


[Later edit]

After further digging I see that I just need to add [TOC] at top of my Markdown Preview Enhanced page and I generate table of contents.

https://github.com/shd101wyy/markdown-preview-enhanced/blob/master/docs/toc.md

The missing part is to get this into Scribus but I have worked out the route.

[a.l.e]

@dragonfly, i don't think that creating a TOC in pandoc will work, since you don't know how the markdown will be layout in scribus...

btw, creating a TOC in scribus is not that difficult... what i struggle with is creating an API for plugins that will then be "consumed" by the TOC... (and after a first version of the API i'm creating a new one with the feedback i got... but i'm digressing!)

[dragonfly]

@i.l.e - I now see your point. I will put more thought into this.
I have not even looked into Scribus source structure yet, but I will now.
Are you the only developer working on Scribus futures (1.6.0 ?).

[a.l.e]

no, i'm not the only developer and i'm not even one of the main (core) developers... but i've been working (for a long time) on a few cool features for scribus...
... and now they seem to get to a point where they are almost ready for being added to scribus.