[Scribus] How to update a link?

[Christoph Schäfer]

Louis Desjardins schrieb:

>>Bonjour Louis,
>>
>>Louis Desjardins schrieb:
>>
>>
>>>>What do you other guys think?
>>>
>>>
>>> I am with you, Christoph. Users can expect Scribus to leave things as
>>> they were on the last save.
>>>
>>> In response to Frank Cox's suggestion, I am with Craig. I don't think
>>> we need a specific dialog for that.
>>>
>>> Nonetheless, this raises an issue about updating links for images.
>>> IMO, the dialog "? la Quark" is half way good and should not be taken
>>> as a model. What we really need is a feature that would search images
>>> not only at the first level of a folder (like it does in Quark) but
>>> within any element within a (user) designated folder (so, folders
>>> within folder - at any depth). That way, if images have been moved
>>> around for *any* reason, links could easily be recovered "at once",
>>> without the need to check manually for each and every image as it is
>>> right now (unless of course the images are not within that
>>> arborescence). The reference could be the time of modification and/or
>>> other info that devels know better than I do to determine wether an
>>> image was actually modified since it was imported and fitted into a
>>> Scribus page.
>>
>>I think what you describe is not only Quark's behaviour, but most, if
>>not all desktop applications do more or less the same. They will either
>>search in the last known directory, the default directory or another
>>previously opened directory. The reason is the developers can't know
>>which is the best solution and IMHO there is none. Much depends on the
>>user's preferences, and it's a matter of taste.
> 
> 
> Let's take a real life example. You have a book and for each chapter 
> a set of images. These images are stored into an arborescence, 
> chapter per chapter. Say you move the mother folder. All your links 
> will be lost. To restore them, you'll have to go to every 
> subdirectory and relink. It will be fastidious. If you have a 
> subdirectories link capacity, it's going to be a breeze. If all 
> programs work like that *so far*, well, isn't it time their devels 
> know there is a need for better?!
> 
> 
>>As for searching in subdirectories, I'm not sure what will be the
>>appropriate criteria for deciding if an image is the "right" one. At
>>least on Unix-like systems "find" has a universe of opportunities to
>>search for files, but which to apply? I think Craig's suggestion to use
>>dimensions, resolution, and, perhaps, the image name will be enough.
>>Dimension and resolution are reasonable criteria, IMHO, because even if
>>another image will be imported, the settings chosen for the previous one
>>still make sense. What do you think?
> 
> 
> As everybody else, we rely on the folder's belonging and the 
> date/time of last modification. This usually work in most cases. I 
> can't say for sure what I prefer it to be. What I know for sure is it 
> has to be a solution fitted for "human" beings! The name of the file, 
> with the date, or the creator, and/or the resolution... This all 
> makes sense to me. Adding the arborescence capability would only make 
> this work better from the user perspective. The program will not be 
> asked to search for a pic anywhere, unless you select your home 
> directory... So an organized user will always be well suited with 
> such an approach. I think.

Well, actually I can think of a simple approach used by other apps such 
as OO.o: In "preferences", we need an option to save the paths to images 
or text as relative paths. It might help if this could also be chosen 
while importing pictures (i. e. for each picture). Moreover, it should 
be possible to change the general path in "Manage Pictures". So if the 
project folder used to be /home/xyz/documents/project/ (including 
subdirectories), we should be able to change this to 
/home/xyz/documents/next_project. All files will be found again after 
moving files and directories.

This brings up another thought: Maybe it will be possible (in the 
future) to create a project instead of a file. By project, I don't refer 
to what QXP calls a "project", but a directory, including subdirectories 
for text, graphics, profiles, maybe (copies of) fonts etc and of course 
the sla file on top of them. This might not be too much work as it's 
similar to "document templates" and "collect for output".

Your turn ;)

Christoph


> To you!

> Louis