[Scribus] What do you think about a Scribus Server?

[Ludwig M. Solzen]

> What do you think about a Scribus Server version?

Good idea. Server-side document composition is a key asset for an automated
publishing workflow.

The way it is done today is quite abstruse. There is XSL-FO, CSS and TeX. In
all of these cases the content data (author's texts, images, etc.) is stored
in a database, e.g. MySQL. With a query, an XML file is output, which is but
an hierarchical structure of the content data. In order to display the
content in a pleasant and reader friendly way, this XML-file needs to be
mapped with a predefined style sheet. Before this is possible, the original
XML content file likely has to be transformed (using XSLT) into an XML-file
that complies to the style sheet. To define such a style sheet (layout
template), either XSL syntax is used, or CSS, or TeX documentclass
(http://en.wikibooks.org/wiki/LaTeX/Page_Layout). In the first case, the
processor that does the actual typesetting and page lay-out, is a Formatting
Objects Processor (FOP), e.g. Apache FOP. In the second case, I only know of
Prince (proprietary, see http://www.princexml.com/overview/), which does the
processing. All of these are able to return a pdf. In the third case, the
typesetting is done by the TeX engine, e.g. pdfTeX. 

Designing stylesheets (layout templates) is quite cumbersome, since in all
the above cases, this cannot be done but by actually coding the presets.
Designers, however, need to have a graphical interface. Scribus has a
graphical user interface, which allows designers to intuitively create a
lay-out. If Scribus could be able to generate CSS, XSL, and TeX templates,
these templates could afterwards be used to server-side process and typeset
XML data.

The server-side processing could be done using one of the afore mentioned
engines (pdfTeX, Prince, Apache FOP). Or it could be done by a server
version of Scribus. Scribus still doesn't support OpenType Features, and
neither does it have a good typesetting engine (e.g. no control over H&J,
word spacing, etc.), but it soon will. Afaik, Apache doesn't support
OpenType either, nor has it controllable line-breaking algorithms--and
likely it won't soon. pdfTeX/XeTeX does extensively support OT and has
highly refined line-breaking algorithms. So, I would go for pdfTeX/XeTeX.

If Scribus soon will have support for OpenType features (HarfBuzz?) and has
a typesetting engine that will compare to TeX (or would even natively be
able to use the TeX engine), Scribus could be used as a server-side
processor for high quality typesetting. But it could also be used for
client-side post-processing of automatically generated documents. (The user
could have Scribus do the vast amount of typesetting, using a CSS/XSL/TeX
style sheet, while afterwards manually correcting the result, within the
Scribus GUI.)


Feature requests:

* Support for XSL, CSS and TeX documentclass templates respectively;
* Saving Scribus layout templates in the XSL, CSS and TeX documentclass
formats;
* Exporting Scribus documents to XSL-FO format (.fo);

* Enabling pdfTeX (or yet other TeX-flavours) typesetting engine as an
alternative (but natively supported) text layout processor (on text frame
level, rather than document level);


Ludwig