[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>

> hi louis,
>
>
>  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.
>>
>>
>
> anything against setting the maximum image resolution to a lower one in the
> pdf export dialog?
> and unchecking the setting once you go to production?
> (ok, it may use some calculation time while exporting)
>

Exact. We want the fastest possible track.

>
> we are an open source project and we aim for good solution not ugly hacks
> :-)
>

Well... sometimes you have to have your hands in the dirt. Sometimes there
are no better ways!

>
> if that settings is not enough, it would be indeed nice to have an option
> "use image previews" in the pdf export dialog.
> just below the checkbox for the maximum image resolution...
>

Yes, that’s the typical answer: let’s put an option. Expected! :) As long as
this option is *not* the default and becomes automatically unchecked just
after the "Print" button is hit, then I think we could at least consider
adding this!

>
>
> another way of doing, would be to create a script which generates a preview
> for each image which does not have one and switches all the paths... should
> be easy to do...
>

That opens up the door to another issue. Production people are lazy. It’s
something they share with most of the other human beings, so it’s no real
surprise! We don’t want to import again pictures. So changing the names or
changing the paths is not the preferred option. Say we have an image folder.
All images are "as is", not yet calibrated for the purpose of the
publication. They are what we call FPO, for position only. Once they get
calibrated and quality control checked, they have the same name, they remain
in the same folder. All they are is updated since the import time. Then it
only takes seconds to update a whole publication, no matter the number of
pics.

But this is the user point of view. We might in fact enter in collision with
the programmer’s propension of being lazy too. They too are human beings! :)

Louis



>
>
>
> this is what i expect from an open source DTP app! :-)
>
>
> tea time!
>
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus mailing list
> scribus at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20100803/9aff0e24/attachment.htm>