[scribus] a new ebook

[Peter Nermander]

> this are your wishes, of what scribus should be able to do!
> but you don't answer the questions about how it should work, with which
> software it should be compatible, which kind of use we would be mainly
> targeting, which parts should be editable in an external editor and
> which should be kept but not being edited? there are lot of open
> questions...

As I said, the import filters should be able to use regexp to apply
any formatting available in Scribus. Regexp is regexp, and the
formatting available in Scribus is the formatting available in
Scribus. Do I really need to expand on that topic?

As for a special "Scribus text format" that is an open issue. Possibly
it could just by native Scribus XML and be edited by any XML capable
editor? The point is that it needs to be a structured format. I have
to confess I haven't looked at the SLA format for a while, but it
didn't use to be structured according to the document structure. For
example the position of frames used to be controlled by attributes
rather than the order they occurred in the file. But maybe this has
changed?

> you've been told that it's a good idea, but now we are asking you to
> explain us, how you think this should work...

Like XLST.

> - getting scribus to manage linked text sources is much easier (and
>  likely to happen in a near future) than being able to park your car on
>  the moon, but it's still a hard task. i think we could try to target
>  the GSOC 2013, if we find a student willing to work on this!

Compilers have been supporting #include for a very long time, how hard
would it be for Scribus to perform "inclusion" like that when the
document is opened? Maybe we could just use m4 as a preprocessor when
Scribus opens the document?

/Peter