Tiff's with jpg compression in Quark

dandraver

New member
I don't have a problem placing files into InDesign, but when I get a job with large tiff files that I try to save with jpg compression, Quark doesn't recognize them. Is there a workaround for this? An update or an extension?
 
Re: Tiff's with jpg compression in Quark

Dan,

currently XPress does not - as far as I am aware of - provide a TIFF-import filter that allows that. You have to resave your images.

Regards,

Peter
 
Re: Tiff's with jpg compression in Quark

If you realy need them compressed use LZW, but its better not to compress, it wil only mean more work for your RIP later.
 
Re: Tiff's with jpg compression in Quark

It's going a little off subject, but...

> If you realy need them compressed use LZW, but its better not to compress, it wil only mean more work for your RIP later.

Two things here:
a) Beware of the differences between LZW and JPEG - one is lossy (JPEG) and the other lossless (LZW). For a lot of images, using lossy JPEG will reduce file sizes and look OK, but if you push the lossyness too much you'll end up with artifactes when rendered. Personally, when producing PDF files I prefer to use zip/flate as it produces better compression than LZW whilst still being lossless (although it does take longer to compress than LZW, so if time is of the essence, I prefer LZW).

b) The comment above re "its better not to compress, it wil only mean more work for your RIP later" is actually not strictly true and is mis-information to some degree. Although the RIP will have to do more work in 'getting the image data" as it will have to decompress it, a RIP will typically work faster if an image is LZW compressed than if it is not. What you exclaim!! Why's that? Well, the RIP has to read the job you are sending it, either from disk or across a network. An uncompressed file means either reading more data from disk or sending more data across the network. Modern RIPs are pretty good at using parallelism, For example RIPs will often do things like asynchronously read data from disk or asynchronously read data across a network - because the CPU is much faster than the data rates from disk or across a network. Whilst data is coming in asynchronously, with uncompressed data the RIP (CPU) is idle and doing nothing, just waiting for the data. However, with compressed data, the RIP can use all those spare CPU cycles to do the decompression. The end result can often be a faster RIPping time.

In my view, I would always compress images if possible, as it will mean a more efficient workflow (especially if the job is copied around - for example it's backed up as well as being RIPped, or might be re-RIPped), and possibly even mean less work for your RIP. Even if it's the case that it's not much more work for your RIP, your overall systems should work better, as your disks will fill up slower, less data will be motoring around your network, etc...

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top