[Scribus] How to update a link?

[Louis Desjardins]

Asif Lodhi a ?crit :
> Hi Christoph,
> 
> Christoph Sch?fer wrote:
> 
>>Hi Asif,
>>
>>Asif Lodhi schrieb:
>>
>>>Hi,
>>>
>>>I go with Christoph's idea X............................................
>>>   
>>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.

BTW, what you describe here is almost exactly how we deal with related 
files in our shop. Only, this is not driven by the application itself 
(in this case, Quark) but at Finder level (on Mac OS X). Basically, when 
a new project is started, it gets a serial number and we simply 
duplicate a "main" folder that has all the subfolders we need, empty. 
The main folder gets the serial number. It's so easy and so efficient. 
And we have full control on how this tree is build.

However, as a separate discussion, there is still a need to better 
handle updating links than what it is at the moment ? even if all known 
apps work the same. Searching into an entire volume or part of it should 
be left to the user's will, with the following limitation : search into 
a "mother" folder and its children, at once. The program shouldn't look 
for pictures where you don't want it to. So, not uphill searches... only 
downhill. I can hardly see an issue with such a way to go and it could 
improve dramatically the relinking of images ? it is an everyday task 
when dealing with files coming from all over the city where we have no 
control on how things were put together. Of course, this is from the 
user's point of view.

Cheers! And a happy new year again!

Louis

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

> Acknowledged & agreed!  I talked about content management system because 
> having a project directory like the one you have described would also be 
> a stepping stone for a possible content management system because 
> content  (scrapbooks, vector, etc.) would be stored in different folders 
> (symlinked or otherwise) - which can be managed because they are 
> external to sla.  I mentioned the idea of a possible 
> strategy-pattern-driven content management system since there was a 
> discussion with regards to content management systems (storing text in 
> databases, perhaps) earlier on this list and, IIRC, inadequate 
> performance of some version control application was also mentioned.  
> Perhaps, developers can see my point.  The whole idea of storing 
> referenced resources (fonts, text, scrapbooks, etc. - as you have 
> mentioned above) as part of the project, perhaps, could be implemented 
> in a location-independent manner as well so that the hierarchy of the 
> content would stay the same - intact - but the _location_ of the content 
> may not necessarily be sub-directories - it could be database tables or 
> data files generated by some specialized storage/data engine well suited 
> to the job.  All I am saying is:  if  at all considered implementable, 
> code for the hierarchical structure should be implemented in a 
> location-independent way so that even if, for the time being, Scribus 
> doesn't use specialized data engines for storage, it could use them in 
> future - without disrupting the code.  Simply speaking, the code for the 
> project directory structure should be location independent and focused 
> on hierarchical storage & structure rather than the method/medium 
> (directories/files, disk, etc.) of storage so that the storage medium 
> can be replaced by data engines, content management systems later.  
> Talking about content management systems, I would duly like to mention 
> here that even XML can be stored in XML-centric data engines now.
> 
> --
> Best regards,
> 
> Asif
> 
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
> 


-- 
Louis Desjardins
Mardigrafe inc.
T 514 934 1353
F 514 934 3698
http://www.mardigrafe.com