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