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
