>> I am not sure why you would want to create the e book format directly > from Scribus.
> Let me answer this question why I would want to produce an e book, It > has already been partly answered. > ?It's called single source methodology :) Typeset once, read > everywhere.? That was not the question. Nobody has questioned that "typset once, read everywhere" is good. The question is if Scribus is the right tool for it. One main reason that Scrbus is not suited for the task is that Scribus documents are not structured. Structure is the most important part to be able to convert to as many formats as possible. Imagine a Scribus page with four text frames. They are not linked. How would an export function know in what order to export the text? Starting in the upper left corner, going right and then down? Would that always be the intended order? I doubt. Imagine someone using inline graphics for bullets or drop caps, how would an export function realise that? I can probably keep on giving examples, the main point is that when reading a printed publication you don't have the slightest idea in what order the parts were put on the paper. You can place the glyphs in random order, the page will still be readable. But putting the glyphs in random order in an ebook won't work as good. You can drawn characters instead of a font, can still be read on paper, but in an ebook it won't work as good. So, once again, why should Scribus be the "hub"? Wouldn't it be better with a SLA export from Libre Office Writer or Calibre? Or a SlaTex? I think Scribus would be better of as one of the end nodes and some other application/format would be a lot better as the "hub". /Peter
