[Scribus] XML format used in Scribus

PLinnell mrdocs
Sat May 14 22:05:42 CEST 2005

On Saturday 14 May 2005 19:40, Gregory Pittman wrote:
> Marvin Dickens wrote:
> >Question:
> >
> >Is the XML format used in version 1.3 stable or will it
> > change/evolve more before version 1.4 is released? Also, what is
> > the possibility it will change/evolve again as development
> > versions 1.5/1.6 progresses?
> >
> >The reason I am asking is that we want the ability to massage
> > Scribus Documents in their native XML format and I do not want to
> > reinvent the wheel with every new release.

Right now freezing to a stable point is impossible to promise, nor 
practical to consider.  Otherwise, this cuts of feature enahcements 
or optimizations we might find.

> I think it's been pretty clearly stated that so far, the formatting
> of 1.3 files is unstable, thus the admonition to not use 1.3cvs for
> production work.

Correct. 'admonition' is a good way to put it too ;-)

> The last I checked, the original XML-like formatting of Scribus was
> not considered "well-formed", at least by Perl XML parsing modules.
>  The problem there largely seemed to be the use of Ctrl-E as a
> newline-equivalent in the files (when I got rid of the Ctrl-E, they
> parsed).  XML parsing presumably stumbles on Ctrl-anything.

Part of this is a Qt issue as far as I know. Fixing this means major 
breakage in 1.x. file import.

1.4 will have 'well formed' XML and it will be very clearly 

> It seems to me that these "soft" newlines should not be part of the
> file as saved, but simply be internalized in the way that the file
> is ultimately displayed by Scribus.  Once the file is transformed
> to a format in which this is hard-coded (such as PDF) then the
> point at which Scribus made that line break should be codified.
> I have to say that I am concerned that, from my assessment of
> various Scribus-list messages, there is no plan envisioned for any
> capability for Scribus versions 1.2x or below to be able to handle
> >1.3x files; not even conversion utilities. 

No DTP I know can do that cleanly, except Illustrator and some other 
vector drawing apps. 

Note: I mention cleanly.. IME there are always some issues. 

However, when you "backsave" you lose higher level features. In this 
case of EPS, export from Illustrator 9+, this enhances its 
conformance to EPS specs. In my experience this is almost a necessity 
for working in cases like Illy 9+ > Pagemaker 6.5+. There are others 
I know of too.

Pagemaker 6.5 can open 7.0 files, except if they have PDF => 1.3 
placed in them. 

These cases are exceptions to the rule that "backsaving" to an older 
format is easily doable in DTP.

> >I can understand that 
> there are features of 1.3x and beyond that do not correspond to
> prior versions, but the result is that at some point anything <1.3x
> will suddenly be crippled.  One then must worry that at some point
> advanced versions will then not be able to load anything <1.3x.

We have discussed creating a special file loader to convert older 
1.2.x docs into the new file format - if -  needed. 

Scribus 1.2.x will open Scribus 0.4.8+ docs.  Franz and I have kept 
quite a few old files around from various 0.X versions to test 
backwards compatibility. 


More information about the scribus mailing list