[Scribus] How to update a link?

[Christoph Schäfer]

Hi Asif,

Asif Lodhi schrieb:

> Hi,
> 
> I go with Christoph's idea of thinking of _all_ the Scribus-related 
> documents as a project and putting them under a project directory - that 
> means copying the images you want under your project directory tree, 
> like you do when creating a website, and using _relative_ links to all 
> referenced external resources (images or whatever).  I would like to 
> mention the functionality of Macromedia DreamWeaverMX2004 as an example 
> - it asks you if you want to copy the image under your website's home 
> directory tree when you try to insert an image in one of your webpages 
> and that image is outside your website's directory tree.
> 
> This discussion also reminds me of Java's way of handling the JAR files 
> - all the project's files are _zipped_ in one file - but under a project 
> diretory.  Though I am not proposing using zip/jar files for Scribus but 
> a similar approach, perhaps, could be useful.
> 
> The problem of having to find all the referenced image files in 
> different directories also reminds me of Java's way of handling 
> class-paths - you don't specify a single directory - but a number of 
> directories to search for files - that is, a list of image directories 
> could be specified through the preferences dialog to search image files 
> if they are not found under the project directory ...  So, when you move 
> your .sla to another system you only have to change the path in one 
> place using the preferences dialog.  Of course, searching files does 
> take a bit of time - that won't happen if you use relative paths - the 
> search can start first from the home/project directory.
> 
> Thinking in terms of a project and using relative links (instead of 
> going for a jar/zip file approach)  is better if we think in terms of 
> content management systems - a content management system that uses a 
> different strategy (the pattern!) to manage the textual content and a 
> different strategy to manage the graphical content (images - bitmaps, 
> vector files, etc.) - the top-level strategy (the parent from where all 
> the lower level strategy-related classes are derived from, that is) will 
> be the same/parent.  Perhaps, out of workflow optimization issues, 
> images could be put on a separate hard-disk in a separate content 
> managemnt server (the image directory being linked/mounted on the local 
> disk) so that the graphic artists as well as the DTP experts could work 
> in parallel.  When everything has been finalized (images are approved, 
> text has been proofread, layout is approved, etc.) and those files are 
> needed together in one directory - perhaps Scribus could use some kind 
> of an export/collect functionality.
> 
> Developers, you see my point?  Don't you think that if you use strategy 
> pattern then you can you use the same content managemernt system to 
> manage different content (images, web pages, .sla's, etc.)?  Don't you 
> think _all_ the different referenced images/resource can be put in a 
> single/file (some kind of a jar-like file) when they are needed in one 
> place in one file?  Instead of zeroing in on a _single_ storage/data 
> management solution, the content management could use a different set of 
> storage/data management engines in each case (web design/development, 
> Scribus slas, images, etc.)
> 
> Just my two bits!
> 
> --
> Best regards,
> 
> Asif
>

Your ideas sound reasonable, but one has to take care not to make it too 
complex, at least as a first step. I'll try to explain what my idea was 
in the first place:

A Scribus project (in contrast to a simple sla file) would be made of a 
directory and its subdirectories. When starting a new project, the user 
will be asked about the name of the project, which will also be the name 
of the directory, and about the location of that directory. The user 
would also have to define which files will be stored in subdirectories: 
images (bitmap, vector), text, fonts, profiles, scrapbooks etc. For each 
possible category, a subdirectory will be created. Moreover, the user 
would have to choose whether a local copy of each file loaded into 
Scribus will be created. That way, the original files will be not 
affected if they are edited. Of course, by default, all files will be 
stored in relative paths (at least by default). Saving the project will 
update the sla-file and all subdirectories. If done so, the project 
directory can be moved around without any hassles. It is some kind of 
collect for output backwards, since collecting for out put does this at 
the end of the process.

That part of the proposal will be a convenience for small projects with 
one or few editors, but it will probably eliminate some typical sources 
of errors. When multiple editing is possible, one could think about more 
complex options such as a project administrator who will decide what 
will be allowed to be edited and by whom. One could also think about 
network directories, symlinks and other necessary things. But all of 
that would be step two. If step one could be achieved, this might be a 
really handy feature. And to be realistic: Scribus will probably be an 
alternative for small shops first, so their needs should be suited 
first. Then it will possible to move on to the big boys (newspapers, 
magazines etc.)

Anyway, just my personal opinion.

Cheers,

Christoph