> 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
