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 : http://ahnews.music.salford.ac.uk:82/documentation/pdfs/docformat0.8.pdf 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 ? http://ahnews.music.salford.ac.uk:82/documentation/pre-press.html 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, Regards, Peter
