[Scribus] Project management

[scribus at bloomingpouf.com]

It's the Old Argument about making things Fool Proof, supposedly quicker 
and more user friendly! User Friendly.. I often wonder if it's an 
Oxymoron 
<http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=oxymoron> - 
like Military Intelligence. One hell of a lot of hype has been placed on 
The User Friendly Idea for years.. and as many folks know, it's not 
about users but programmers and developers showing off!

Yes it would be lovely to have a File Format/Project Archive that holds 
everything in one place and can be easily moved about. It makes 
transport easy and allows for lax file management - and then there will 
be the demands for versioning within such a file format with hundreds of 
levels of backup and undo.... and the file becomes Bloat Ware, which is 
what most open source is supposed to be getting freely away from.

 From experience with using programs that do this the System Hit is 
onerous, especially if  like many folks who have turned to Open -Source 
Software you have been obliged to do so due to Finances - and this limit 
also impacts on the speed of system that you have. How we would all love 
to have the latest processor with multi gig ram and matched SCSI drives 
mirroring and stripping as fast as possible, and that 24 inch LCD 
monitor... no make that two - and that lovely USB coffee cup warmer 
plugged in on the side.... Dream On! My personal shopping list runs to 
over 10 Grand Sterling... so unless the lottery pays out, I have to mend 
and make do! So do many other folks.

There is no substitute for good practice in managing files - knowing 
where they are on your system - and working with the software and not 
demanding that it be something that it is not.

The Development of Open-Source Software is for all comers - and even if 
some programmers and script kiddies think they are God... well miracles 
take time and can only occur with the Space Time Continuum that we are 
presently working in! There are limits that will take time to resolve - 
in the mean time good practice and good management of files is the best 
option.

TTFN

@~>~>~~~

Asif Lodhi wrote:
> 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
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20071001/c18b6afa/attachment-0001.html