[Scribus] XML format used in Scribus

[Marvin Dickens]

On Saturday 14 May 2005 01:40 pm, 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.
>
> 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.

I'm not using 1.3 for production work nor did I say I was. My question
was when/if stability would be reached.

> 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.

Yes and no - Depends on the implementation on both the part of the XML 
document you want to process and the tool(s) your going to use to process
the document with. I've been following involved with XML for years - I've yet 
to find a parser that could give the results we needed without some kind of 
modification(s). This includes Perl XML parsing modules (Which I've used for 
years).

> 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.  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.

Personally, I am not bothered by a lack of compatibility between versions.
I'll run older versions concurrently with new versions. 

> TPFKAG