[Scribus] Project management

[Asif Lodhi]

Hi Roger,

On 10/1/07, Roger <hovergo at net-tech.com.au> wrote:
> While we work on a project, everything is separate but when assembled for
> production the components are assembled into one .sla.

Yes, but in Scribus, you assemble everything in a PDF, don't you?

Please note that SLA is a plain-text document format (you can open an
SLA file in your Windows Notepad) based on XML - which is a very
complex markup language. It's relatively very slow to process and some
folks keep coming up with faster versions (e.g. fastInfoSet) for
different needs yet we always need a faster XML processor nonetheless
- thanks to XML complexity.

I think embedding images in the SLA itself would mean converting the
byte-stream of each image file to hugely long text strings (to comply
with the cross-platform text portability of XML, for one reason) and
vice versa - which would result in substantial processing overhead.

Since Scribus does not just save the final output in XML-based SLA but
it also processes/writes XML continuously in the background as you
edit your SLA documents, the complexity of XML does not, at least
currently, warrant the option of embedding images in the SLA itself.

The equally valid suggestion of compressing the whole thing in a zip
file is impractically slow for the same reason - complexity of XML and
the hefty cost in terms of the time which is required to process it.

So, the matter of embedding images in the SLA files boils down to the
problem of coming up with a faster XML processing library/algorithm.
Likewise, the matter of compressing images & SLA together in a zip
boils down to that of an incredibly fast compression
library/algorithm. I don't think any of the two library/algorithm
currently exists.

Just think how much time your favorite compression program takes to
inflate/deflate your zip files and then just imagine Scribus having to
continuously edit the complex XML in the background along with the
stringed binary streams of images stuffed in the same SLA and that too
in a "zip" file! To me, it's a can of worms - at least, currently.

Though I won't discuss it any more but I do think that these
discussions do present radically new
requirements/problems/opportunities, such as the libraries/algorithms
to process zip and XML files at incredible speeds, for developers
elsewhere who are working on such algorithms/libraries.

Just my humble opinion.
--
Best regards,

Asif