[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: mark barratt <markb@xxxxxxxxxxxxxxx>, FrameUsers List <Framers@xxxxxxxxxxxxxx>, Frame List <Framers@xxxxxxxxx>
Subject: Re: FM+SGML: slow screen redraw
From: Jay Smith <jay@xxxxxxxxxxxx>
Date: Mon, 04 Jan 1999 10:19:35 -0500
Organization: Jay Smith & Associates
References: <3.0.5.32.19990104114533.008cb6e0@textmatters.com>
Sender: owner-framers@xxxxxxxxx
Mark,
Your slow screen redraw problem is probably because 1) you are using
TIFFs and 2) you did not mention it, but if you are working over a
network, and the TIFFs are on the server, that will do it too.
We do not use TIFFs for two reasons; this is one of them. (The other
reason is that most/every program interprets the TIFF image data and
does so potentially differently; thus the same image *might* print
differently from application to application or version to version.)
For ALL our images we use EPS format files with a 1-bit preview. EPS
is a file format, not just a type of image (i.e. not just vector).
(Most/all [?] applications only read the EPS header and preview data
and do *not* interpret the image data.)
EPS files tend to be twice the size of TIFFs, thus there is a bit of a
problem there. However, in my opinion, you will have more consistent
image appearance over time. Also, the 1-bit previews write to the
screen very quickly -- though they look terrible. For our purpose,
the important thing is to know the size and to be able to generally
tell that it is a picture of a person and not a horse (or whatever).
If EPS is not a satisfactory answer, then you will have to have your
images on a local hard disk and pay some money for the biggest,
fastest graphics card you can find -- with a huge amount of memory.
Also, the fastest internal (bus?) speed of the computer for
communications between the graphics card and the main board -- double
that and you *may* halve your redraw time.
I am also sending (to you only; others by request) a bit that I wrote
on benefits and drawbacks of using EPS images.
--
Jay Smith
e-mail: jay@jaysmith.com
The Press for History(tm), The Press for Education(tm),
The Press for [Your Industry](tm), The Press for....(tm)
On-demand printing and binding of hardbound books.
Minimum run one copy.
P.O. Box 650
Snow Camp, NC 27349 USA
Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
1-800-447-8267
Fax: Int+US+336-376-6750
mark barratt wrote:
>
> I have a series of SGML jobs used to produce (among other things)
> full-colour printed brochures with colour photos.
>
> The pics are held as CMYK TIFFs, imported by reference, each pic is between
> 4Mb and 8Mb in size. This makes for cruelly slow screen updates (several
> orders of magnitude slower than opening the same pics in a Quark Xpress
> file, for instance).This in turn makes the 'cycle time' for checking
> WYSIWYG pages or doing small corrections very silly.
>
> Any ideas, other than improving hardware, network and server performance?
>
> I thought maybe using DCS-format pics might help, because they use a
> (smaller) preview file?
>
> BTW: the screen redraw time problem is common on the platforms we use (Mac
> and Win95) and the versions of Frame (vanilla and +SGML).
>
> And happy new year...
>
> ____________
> Mark Barratt
> Text Matters
> 37 Upper Redlands Road, Information design:
> Reading RG1 5JE, UK We help explain things using
> phone +44 (0)118 986 8313 .language
> fax +44 (0)118 931 3743 .design
> email markb@textmatters.com .systems
> web http://www.textmatters.com .process
** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body. **