[Scribus] How to update a link?

[Asif Lodhi]

Hi Greg,

Sorry!  Only now I see that I top-posted!  Looks like I just scribbled 
away the message in too much a hurry!  Sorry guys!

Gregory Pittman wrote:

> I think you may be right about this, but it seems this is more of a
>
>"best practices" kind of advice, that might do well to be on the Wiki so 
>others can avoid subsequent frustration.
>  
>
It was Christoph's idea so he is the right person to do it.  (Besides, I 
have forgotten everything about how to put stuff on Wiki! :)

>>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.
>>    
>>
>For some, this may be the preferred way of working -- having a static, 
>well-organized image directory with subdirectories, and in that case, 
>they might not want the bother of making copies elsewhere.
>
>  
>
>> 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.
>>    
>>
>One thing which has occurred to me is that, even though some of the 
>Scribus team seem to wince at the thought, the fact that .sla files are 
>text-based means that, even if one commits a "faux pas" such as David 
>did, it is possible to load the .sla file into a text editor and do a 
>search-and-replace operation to fix all the image references in the .sla 
>file.
>  
>
Yes! :)  Text files can easily be changed.

Actually, because of skimming through this thread and the kind of work I 
am currently engaged in, it occurred to me that a DTP workflow could be 
organized using a content management system that made good use of the 
"Strategy Pattern" which means that developers could use a generic 
strategy for the base content management system and domain-specific 
strategies for .sla's and DTP related work, for example - that is, the 
child strategies derived from the generic top-level base strategy 
(genuinely super-functional polymorphism in play!).  That way, 
additional strategies could be derived from the generic one so that the 
same content management system could  manage additional types of content 
- for example, web design, SVG, etc.  Since different domains (DTP, web 
development, etc.) have different disk-IO requirements, the content 
management system could employ different storage/data management 
engines/technologies to take care of each.  Since managing different 
types of content on the same disk/system could be a potential bottleneck 
due to disk-IO requirements of each, different types of content could be 
stored in different data/cms repositories residing on different systems 
- all repos being controlled by the main cms in a location-independent 
device-independent manner - I am thinking about Jini when I am writing 
this (because of the location/device independent stuff).   Storing each 
type of content (SVG/EPS, SLAs, Web pages, etc.) on different machines 
would enable domain-specific experts (vector graphic artists, dtp 
experts, for example) to work efficiently on their stuff.  The 
domain-specific content would be managed by the domain-specific strategy 
pattern derived from the generic strategy pattern of the main content 
management system.  There would be no deficit in performance in managing 
the content since storage/data repository management code 
(domain-specific strategies, that is) for each type of content would be 
specifically written to manage that specific type of content.  This is 
important because using CVS for code is different from using the same 
for SLAs - each has different IO/performance requirements.

Talking about the jar file, IIRC, the jar uses the same zlib that 
Scribus indirectly uses (JPG lib, PNG lib or another dependent lib uses 
it).  If the developers do plunge into developing a content management 
system like the one I mentioned above ;) then a mechanism similar to JAR 
(1- importing/collecting images from different data repos and zipping it 
into one file so that it can be moved/unpacked elsewhere so that a user 
could work on the content locally) could be employed for the sole 
purpose of keeping _everything_ into _one_ file.  When I am talking 
about this all, I am also wondering about the possibility of managing 
the bitmap content by storing time-stamped history of actions as well as 
structure (layers,  selections,  paths,  channels, etc.)  _externally_ .

Perhaps this (and prior) post of mine doesn't belong here in this 
thread.  I would certainly like to hear from the developers.  What do 
you think?

These are just my views.

--
Best regards,

Asif