[scribus] How can I remove an image from and Image Frame?

[Louis Desjardins]

2010/8/3 a.l.e <ale.comp_06 at xox.ch>

> salut louis,
>
>
>  How can I remove an image from an image frame?  I am using Scribus
>>>> 1.3.3.13svn in Kubuntu 10,04.
>>>>
>>>>
>>>>
>>>>
>>> Undoubtedly not the proper way to do it, but I found (inadvertently) that
>>> if you move the location of the image, it disappears  from the frame!
>>>
>>>
>>>
>>
>> Now this is unexpected! The program should instead mention that there is a
>> broken link to an image and still be able to show that image at low
>> resolution. It should simply ask to restore the link.
>>
>> I wonder what are the reasons why the image should disappear. This leads
>> to
>> prgramming concerns.
>>
>> Back to the initial question, one other way of removing an image from an
>> image frame is getting a new one into the same image frame. One image will
>> simply replace the other.
>>
>>
>
> by default, scribus does not store the images in the .sla file so showing a
> preview is not really trivial.
>
> in 1.5svn there is an image cache... so it may be possible to show a lowres
> preview for missing images: but it is really needed?
>

There is often a need to produce quickly a print of a file. While in
production, we can produce dozens of proofs for various reasons and at
various levels: creation, to see, compare, test; production to check overall
quality, look for defaults, all of those being internal proofs; and we have
the proofs that go to the client, come back with notes, changes,
corrections, all of various levels. One way to accelerate the printing
process is to get temporarily rid of the high res images and simply print
the pages with low res images (depending on what you need to proof, of
course).

There are various ways to print a proof without the images or with the low
res images. The fastest we found over the years was to temporarily "hide"
the image folder (putting it elsewhere on another level) so the application
doesn’t know where to find the images, asks a simple question through a
warning: "Print anyway" or "Find missing images" (and of course, "Cancel").
When you hit the "Print anyway" button, the job just prints, quickly. There
is basically not much left to process when you take away the images. In this
case, the trick won’t work in Scribus.

There are certainly other ways of achieving the same result. But as quick?
and as quick to revert? What we need is something quick.

The 'hiden folder" way is so simple and have never lead to any errors at the
high res output. Provided your images are all stored in the same folder,
putting this folder away leads to a global warning. Once the folder is back
to it’s original place, the user simply has to identify one of the images
into that folder and the program tells right away that there are other
images in this folder that need to be relinked or updated, and then it takes
a second to solve the issue.

A solution that would create low res images on the fly (and not store them)
would use up time everytime.

>
> on the other side, showing a warning for a missing image, is certainly a
> must!
> this is already the case in 1.3.8 (the name of the missing image is shown
> in red bold letters.) should it be blinking?
>

Yes, we need a warning for missing images. The warning should tell the name
of the image and the program should keep the coordinates of the pictures
once imported in the frame so users don’t waste time redoing the work of
framing properly the said image or images. I can only guess this is the case
now. I hope so! No, I don’t think it should be blinking.

>
> and in the image manager you have a button to search for the missing image
> in selected folders.
> iirc, this tool has already been enhanced in 1.5svn
>

This is exactly the task of an image manager so I cannot agree more.

>
> as i've already, written, it's not a good idea to rename an image to clear
> the content of an image frame and scribus already has a clean way to do it
> (edit > content > clear).
>

Completely agree. But why would someone rename an image to clear the
content?

>
>
> so: are we facing a storm in a tea pot?
>

Erm... I wonder why even mention this. The initial question has been
answered and while we were at it, we have gone into another road,
questionning the actual behaviour of Scribus. Nothing in there looks like a
storm to me and certainly not a storm in a tea pot!

>
> ciao
> a.l.e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20100803/069de44c/attachment.htm>