QTR-Quadtone RIP

Unfortunately, I have no suggestions for you. But, I have been following this thread and I find it fascinating when you said “QTR has a native resolution of 720.” You also said “Roy has stated this in the past and I can dig out his reference if anyone is interested.” I am interested, if you would be kind enough to dig that out.

 

I hope you find a resolution to your issue, soon.

 

Thanks,

Mick

 

From: <QuadtoneRIP@yahoogroups.com> on behalf of "brian_downunda@... [QuadtoneRIP]" <QuadtoneRIP@yahoogroups.com>
Reply-To: <QuadtoneRIP@yahoogroups.com>
Date: Friday, August 24, 2018 at 9:09 PM
To: <QuadtoneRIP@yahoogroups.com>
Subject: [QuadtoneRIP] Re: Error Message concerning TIFF Bitmap Buffer

 

  

Thanks for those suggestions.  The thing I find puzzling about sampling down to 360ppi to solve the problem is that QTR has a native resolution of 720.  So when I send it the 360ppi file QTR will resample back to 720ppi before starting the printing process.  (Roy has stated this in the past and I can dig out his reference if anyone is interested.  Thus anyone who says "just give QTR whatever PPI you have and it will use it" is not strictly correct.  Yes it will print, but only after resampling.)

 

The resolution to this paradox is that on Windows it's the QTR back-end that does this resampling.  I assume it's the QTRGui front end that is complaining that it can't process the TIFF to display a thumbnail to display in the GUI interface.  If you could get past that then it would print.

 

In the cool light of morning I tried my images on my laptop running 2.7.6 and lo and behold it worked!  It still worked after an update to 2.7.8.  I think Dave is right about fragmentation.  But which drive - the OS drive or the images drive?  Both are filling up, and while there's still plenty of space, I suspect that the code in QTRGui wants contiguous space.