> 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
