[Scribus] How to update a link?
Wed Jan 4 22:39:12 CET 2006
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
>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
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
These are just my views.
More information about the scribus