[Scribus] Google Summer of Code 2007

[Ludwig M. Solzen]

> That's true, but I don't think that this is enough for a publishing
> workflow. The idea is that any change you made in Scribus is also
> written back into the CMS, that content is locked if it is currently
> edited in scribus etc. etc..

The concept of editing lay-out (formal representation) and user generated
content (UGC) (text, images, etc) at the same time, within the same file is
to become obsolete. It's precisely this confusion that causes versioning
issues. A CMS, ideally, should not keep track of changes made to an
assembled file (UGC + Lay-out), but of changes to file components
separately.

I think it would be a missed opportunity if Scribus's publishing workflow
would clone Adobe's (Scribus aka InDesign, VersionCue/AdobeBridge aka "CMS",
InCopy aka OOo). Instead, I expect e.g. TeX's concept of strictly separating
layout and content, is more fitting a web-based workflow with heavy content
managing demands and intensive multiple authors collaboration.

Also, privileging one CMS over another would be inaccurate, let alone to
produce one from scratch. There are already several good ones available
(OpenSource), changing from day to day, out of which Drupal, to me, seems
most promising. In any case, all interaction between whatever CMS and
Scribus should go over validated xml.

It is essential to strictly separate content (creating, editing, storing,
exchanging, versioning) from lay-out (creating, editing, storing,
exchanging, versioning), so that they do not become interweaved until the
very end (i.e. generating the print-ready document). Content is created
through a text editor, stored in a database and exchanged via a validated
xml-file; this is all or at least partly the task of a CMS, that expectedly
is web-based. The formal representation of the content (its display) depends
from the context and purpose: within a browser client it is defined through
a CSS, while in print the content has to be layed-out through a
print-specific lay-out template. This is where Scribus comes in.

Ideally, the user designs contentless templates in Scribus. These templates
are created, edited and stored completely apart from the content. A build-in
Scribus Concurrent Versioning System (CVS) would keep track of all the edits
made to the layout template. No CMS needed here: CMS is for content
management only.

When the user needs to do a true lay-out job, i.e. have a print-ready
document being generated, he simply selects a template he or someone else
made earlier on, applies the content by selecting a source path, and Scribus
would flow the content into the template by formatting the content elements
according to the layout specifications of the Scribus template. This is but
a matter of having a 1:1 relation of layout tags (paragraph, character and
object styles) to content tags, both xml. Before applying the xml content
file to the Scribus xml(-flavoured) layout template, Scribus, of course,
first validates the content file (according to a xml schema that complies
with the layout template). If there is no 1:1 relationship, i.e. if some
content tags are not assigned to layout tags (paragraph styles, etc.)
available in the template file, they are formatted by a Scribus default
layout formatting.

At each instance either the content or the layout template is changed
(edited), Scribus would again go through the process. Rather than having the
user to update or to refresh the job he is working on manually, this process
could be automated, e.g. every 10 minutes, according to the user's presets.
The designer gets the newly updated content every ten minutes streamed into
his template, while the text editor gets the newly updated pdf that is
created thereof, whenever he needs.

[ I described this strategy also on the wiki, under "Some preliminary ideas
on how this might work"
(http://wiki.scribus.net/index.php/Draft_of_end-to-end_publishing_solution).
]

IN SHORT: I think it is essential Scribus has advanced xml-import support,
and at the same would allow the user to create layout templates (with
version tracking) that are compliant with preset XML schemas. For each such
XML schema, Scribus would be the tool to both produce the specific layout
template, as to actually generate a print-ready document from these files.

It is recommendable to have a look at what the developers of XeTeX and
ConTeXt are doing. They already have an XML-based workflow, with content
streams going through predefined lay-out templates. The only big issue--or
variant philosophy if you will--is the lack of a graphical interface. Too,
XeTeX and pdfTeX handle OpenType tables and their typesetting engine is
unbeatable, not in the least micro-typographically. Both TeX and Scribus
would benefit from collaboration or at least from an exchange of ideas.

Ludwig