2010/8/3 a.l.e <span dir="ltr"><<a href="mailto:ale.comp_06@xox.ch">ale.comp_06@xox.ch</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi louis,<div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
by default, scribus does not store the images in the .sla file so showing a<br>
preview is not really trivial.<br>
<br>
in 1.5svn there is an image cache... so it may be possible to show a lowres<br>
preview for missing images: but it is really needed?<br>
<br>
<br>
</blockquote>
<br>
There is often a need to produce quickly a print of a file. While in<br>
production, we can produce dozens of proofs for various reasons and at<br>
various levels: creation, to see, compare, test; production to check overall<br>
quality, look for defaults, all of those being internal proofs; and we have<br>
the proofs that go to the client, come back with notes, changes,<br>
corrections, all of various levels. One way to accelerate the printing<br>
process is to get temporarily rid of the high res images and simply print<br>
the pages with low res images (depending on what you need to proof, of<br>
course).<br>
<br>
There are various ways to print a proof without the images or with the low<br>
res images. The fastest we found over the years was to temporarily "hide"<br>
the image folder (putting it elsewhere on another level) so the application<br>
doesn’t know where to find the images, asks a simple question through a<br>
warning: "Print anyway" or "Find missing images" (and of course, "Cancel").<br>
When you hit the "Print anyway" button, the job just prints, quickly. There<br>
is basically not much left to process when you take away the images. In this<br>
case, the trick won’t work in Scribus.<br>
<br>
There are certainly other ways of achieving the same result. But as quick?<br>
and as quick to revert? What we need is something quick.<br>
<br>
The 'hiden folder" way is so simple and have never lead to any errors at the<br>
high res output. Provided your images are all stored in the same folder,<br>
putting this folder away leads to a global warning. Once the folder is back<br>
to it’s original place, the user simply has to identify one of the images<br>
into that folder and the program tells right away that there are other<br>
images in this folder that need to be relinked or updated, and then it takes<br>
a second to solve the issue.<br>
<br>
A solution that would create low res images on the fly (and not store them)<br>
would use up time everytime.<br>
<br>
</blockquote>
<br></div></div>
anything against setting the maximum image resolution to a lower one in the pdf export dialog?<br>
and unchecking the setting once you go to production?<br>
(ok, it may use some calculation time while exporting)<br></blockquote><div><br>Exact. We want the fastest possible track. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
we are an open source project and we aim for good solution not ugly hacks :-)<br></blockquote><div><br>Well... sometimes you have to have your hands in the dirt. Sometimes there are no better ways! <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
if that settings is not enough, it would be indeed nice to have an option "use image previews" in the pdf export dialog.<br>
just below the checkbox for the maximum image resolution...<br></blockquote><div><br>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!<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
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...<br></blockquote><div><br>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.<br>
<br>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! :)<br><br>Louis<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
this is what i expect from an open source DTP app! :-)<br>
<br>
<br>
tea time!<div><div></div><div class="h5"><br>
<br>
ciao<br>
a.l.e<br>
<br>
_______________________________________________<br>
scribus mailing list<br>
<a href="mailto:scribus@lists.scribus.info" target="_blank">scribus@lists.scribus.info</a><br>
<a href="http://lists.scribus.info/mailman/listinfo/scribus" target="_blank">http://lists.scribus.info/mailman/listinfo/scribus</a><br>
</div></div></blockquote></div><br>