[softwarelist] Importing EPSs with TIFF preview (Ovation Pro for RISC OS)

In article <mqfV8HC3L6tFFwAx@xxxxxxxxxxxxxxxxxxx>, David Pilling
<flist@xxxxxxxxxxxxxxxxxxx> wrote:
> Unfortunately what the code presents is the opportunity to
> convert the TIFF preview rather than the PS file.

Yes, I see the command to convert the preview to a sprite:

osclis("wimptask <ChangeFSI$Dir>.ChangeFSI "+from+" "+to+" 28r
-nomode -noscale { > null: } { > null: }");

> It would be quite easy to change things so that you could
> insert a call to GhostScript here.

But at this point the TIFF preview must already have been
extracted from the preceding EPS, surely? So, as you say, at this
stage the only opportunity is to work on the (TIFF) preview
supplied rather than generate a new one, using GhostScript's
sprite device, from the PostScript preceding the preview. Or have
I misunderstood?

> Bottom line here is that I could easily let you call
> GhostScript to make a proxy, but with parameters hard wired
> into the script file.

. . . because there's no dialogue box to configure or control EPS
import. It wouldn't be a problem for me if the parameters were
hard-wired into the script file. If, despite the above, it were
possible to use Ghostscript to make a proxy from the PostScript
it would have several advantages:

i) It would be an easy way of achieving a preview resolution of
more than 72dpi. (A tip from a friend who's a Mac-based designer
is to save graphics as EPSs at several times actual size, so that
their much larger 72dpi previews scale down to a higher
resolution along with the image when placed at its original size
in a Quark (in his case) document. There are times when it is
necessary to see more detail of an imported image than a 72dpi
preview allows, e.g. for accurate positioning or alignment).

ii) There would be no need to include a TIFF preview in the EPS
itself. As recently noted in another thread, the preview itself
can, in some circumstances, be bigger than the rest of the file,
and this all has to be sent to the printer as part of the EPS,
even though the printer itself doesn't use it.

iii) In my experience, with four different PostScript printers
and four versions of Acrobat Distiller over the years, EPS files
embedded in PostScript output sometimes cause rendering of the
page to fail. I have never got to the bottom of exactly what
triggers this -- the same EPS sometimes prints successfully in
one document yet fail in another -- but the error invariably is
'Unknown command "MM"' -- i.e. it is objecting to the "MM" at the
start of the TIFF preview, following the %%EOF[return] of the
PostScript part. Subsequently manually removing the preview from
the EPS (which is easy when using referenced images) solves this,
but wastes time. Again, this would not occur it it were possible
to dispense with EPS previews and generate Ovation Pro proxies
directly from the PostScript instead.

iv) It would lead to smaller Ovation Pro files. At the moment a
ducument containing an EPS with a visible preview has to store it
twice -- once as part of the EPS itself, either within the
document or in a directory of referenced images, and again within
the document as a proxy sprite generated using ChangeFSI.

-- 
P. C. Newble
Fenwood, Church Street, Stoke by Nayland, Colchester CO6 4QP, UK
Tel. +44(0)1206 262946; Mob. +44(0)7944 816266; Fax +44(0)870 055 8343
http://www.newble.com/  ·  peter@xxxxxxxxxx

Other related posts: