[Scribus] scribus xml versus xsl fo?

Peter Linnell scribusdocs
Wed Nov 19 03:38:11 CET 2003

On Tue, 2003-11-18 at 20:12, Mark D. Anderson wrote:
> I've just been looking at apache FOP and Scribus today.
> It seems both contain a renderer from an xml vocabulary
> to print-ready PS or PDF.
> That is pretty much *all* FOP does; it is a command-line too.
> The great thing about Scribus is that it also has a layout gui
> for managing that xml declaration file.
> I can't find any documentation for Scribus' native xml file;
> I just see programmatic parsing in scribusXml.cpp.

Its here : 

This does need some minor updating for the new features, but will give
you an idea.
> Are there elements/attributes declared in the scribus xml
> that are not supported by FO?
> Or vice-versa?
> Are there architectural reasons for Scribus to disregard FO?
> (I notice that Passepartout also uses its own yet-another xml
> vocabulary, and its own renderer.)

Yes. Very much so.

> Are there features in Scribus's renderer that make it
> superior to the renderer in FOP?

Let's start:

No CMYK support in FO. Without it serious DTP is off the table.
Conditionals in the file like is ICC on or off
Arbitrary rendering of postscript features like outlines,gradients,
sophisticated masking and PDF 1.4 transparency which FO does not support
or even contemplate.
High-level features in PDF, bookmarks, thumbnails, javascripting and FDF
data, presentation effects.
PDF 1.5 has layering and other tricks. I expect Scribus will be one of
the first to support this natively.  I know Franz is clever enough to
add this in the future - just time.
Text on a path.
Font sub-setting
Support for Open Type fonts - both TT and Type 1 based
PDF Xobjects.
Support for full level 2 PS, extensive support of PS3
PDF export upto 4000 dpi with CMYK color.

That's a pretty long list. :)

> It seems both have to worry about hyphenation, color, fonts,
> and embedded images.

And more. Waaaay more in DTP. In  pre-press PDF alone there are 5
different "Boxes" in PDF like media box, art box etc. to support.
> Thanks for any insight; I'm just trying to wrap my head around
> the different technological possibilities in this space.

It is my *very* strongly held opinion that the PDF engine Scribus has is
the most powerful, versatile and robust in Linux/Unix land. Period.

Not only is Scribus capable of creating press-ready PDF, but it also can
exploit far more features in PDF 1.3/1.4 than any other stand alone app
in the world short of full Acrobat Professional 6 itself. Not even
Indesign has the same kind of versatility without 3rd party plug-ins.
Not Quark Xpress, not Pagemaker, not Framemaker -tho Framemaker is a
corner case in its support of database driven layout and other features.

What we find is others wanting to work the other way around.. getting
data into Scribus XML and then using the engine to export PDF, because
it so strong in printing features. 

However, where else would you create these sophsticated page layout
features but in Scribus ? 


has a working draft I have written on Scribus PDF quality wrt to press
and printing.

The above  above is based on my professional work which is supporting
pre-press folks and service bureaus, as well extensive testing of
Scribus PDF's with specialist pre-press PDF tools like PitStop Pro,
Markzware, PdfInspektor Best PowerRIP, Fiery RIP's and others.

That said FOP looks like an impressive work, though complicated to
build, That it is based on a W3C standard is a plus to me. 

The admirable Linux/Unix land mentality of bolting together several
disparate tools to accomplish something is one of the things I have come
appreciate since migrating from the Mac/Windows/Novell worls.  DTP is
one of those corner cases where sometimes this doesnt work so well.  FOP
to me looks like a great solution to print structured documentation and
reports etc., but not sophisticated DTP. 

Both DTP and graphics need the interactivity and visual cues only
possible with WYZIWYG apps like Scribus.

Just my .02,


More information about the scribus mailing list