[Scribus] Adaptable layout templates

[Michael Koren]

Ludwig M. Solzen wrote:
> 
> To start with, it would be a good strategy to have Scribus be able to
> process xsl stylesheets and xsl-fo formatted documents (.fo). Scribus
> could
> integrate Xalan (xsl processor) and Apache FOP (formatting objects
> processor)(or ConTeXt) to do the actual processing.
> 
> . . .
> 
> Scribus would also need to import xml content. I suppose that support for
> DocBook would be a commendable goal. The more difficult part is of course
> to
> display the FOP output within the Scribus GUI environment, so that the
> user
> could refine the automated output manually.
> 

For my project, I'm currently planning to support importing arbitrary
structured text formats and mapping them to native scribus objects according
to user-defined layout styles.

My focus is on integrating simple display and manipulation of structured
content into the GUI environment, which as you say is the primary challenge
(without that what's the point of using scribus in the workflow at all? :) .
The main external text import mechanism I was going to develop for the
purpose of this project, which wouldn't be specific to any one format at
all, is a version of the current text import system, where the user defines
their own regular expressions or so to import any kind of structured content
and turn it into structured objects usable by my structured layout engine.

The advantages of this approach are

a) it's doable from the standpoint of scribus's current display
capabilities, since my approach would just manage dependencies between
existing Scribus attributes of different objects, relatively transparently
to the existing code; no new attributes or capabilities would have to be
added to the existing layout engine

b) any kind of structured input can be used if the user feels like defining
filters to parse it :) -- I would use this for my own documents with
relatively simple markup, when a full-fledged standard format isn't
necessary, and it raises interesting possibilites like natively formatting
custom charts, tables, or even equations....

The disadvantage is that manually defining filters to parse and styles to
lay out complex documents could be tedious. As a partial solution, calling
an external XSLT processor as part of the import process shouldn't be a
problem, and maybe even a full xml parser to dump the processed content
directly into my internal structured data representation and skip the user
filters.

I don't see a solution in any case to having to create layout styles in
Scribus, because that's the whole point of using Scribus for the layout,
right? ;)

I'm not personally familar with xsl-fo or workflows involving it. We're
clearly coming at this problem from different angles, but they may be able
to meet somewhere. I'm posting descriptions and use cases of how my idea
would work on my proposal wiki page at
http://wiki.scribus.net/index.php/Dynamic_Layout_Support_Discussion.

Comments about how to impove integration with other workflows, or standards
you would like my engine to be compatible with, are very welcome.

Michael

-- 
View this message in context: http://www.nabble.com/Google-Summer-of-Code-2007-tf3369296.html#a9932410
Sent from the Scribus mailing list archive at Nabble.com.