Received: from [207.113.13.68] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Fri, 20 Aug 1999 12:55:18 -0400
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id MAA18852;
	Fri, 20 Aug 1999 12:40:23 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Fri, 20 Aug 1999 12:31:36 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id MAA18800
	for tiff-outgoing; Fri, 20 Aug 1999 12:31:36 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from srz-berlin.de (ns.srz-berlin.de [212.5.11.1])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id MAA18797
	for <tiff@olympiakos.com>; Fri, 20 Aug 1999 12:31:33 -0400
Received: from SunFrame1 (gw.srz-berlin.de [212.5.11.2])
	by srz-berlin.de (8.8.7/8.8.7) with SMTP id SAA25968;
	Fri, 20 Aug 1999 18:31:28 +0200
Message-ID: <37BD82E0.4E3B@srz-berlin.de>
Date: Fri, 20 Aug 1999 18:31:28 +0200
From: Helge Blischke <H.Blischke@srz-berlin.de>
Organization: SRZ BERLIN
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: tiff@olympiakos.com
Subject: [Fwd: Re: What's wrong with this TIFF?]
Content-Type: text/plain
Sender: owner-tiff@olympiakos.com

-- 
H.Blischke@srz-berlin.de
H.Blischke@srz-berlin.com
H.Blischke@acm.org
Return-Path: <H.Blischke@srz-berlin.de>
Received: from SunFrame1 (gw.srz-berlin.de [212.5.11.2])
	by srz-berlin.de (8.8.7/8.8.7) with SMTP id SAA25889;
	Fri, 20 Aug 1999 18:29:49 +0200
Sender: bla@srz-berlin.de
Message-ID: <37BD827D.3735@srz-berlin.de>
Date: Fri, 20 Aug 1999 18:29:49 +0200
From: Helge Blischke <H.Blischke@srz-berlin.de>
Organization: SRZ BERLIN
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: Alberto Accomazzi <aaccomazzi@cfa.harvard.edu>
Subject: Re: What's wrong with this TIFF?
References: <199908201319.JAA04104@cfa0.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alberto Accomazzi wrote:
> 
> In message <37BC0062.6168@srz-berlin.de>, Helge Blischke writes:
> 
> Kevin D. Quitt wrote:
> >
> > PostScript allows the direct inclusion of the binary CCITT Group IV data from
> > a TIFF file.  My program reads in a TIFF, converting it from multiple strips to
> > a single strip, as necessary, and puts a PostScript wrapper around it.  Generally
> > things have worked well, but with certain images I'm getting a PostScript error
> > in the middle of the TIFF data.  The image was created in PaintShop Pro, then
> > run through tiffcp to convert it to a single strip.
> 
> This is a bit off the point of the original poster, but since this
> question has been bugging me for a while, here it goes:
> 
> is there any way to create a level 2 postscript (or PDF) file which contain
> the sequence of encoded strips (with proper postscript code wrappers
> between them) rather than having to decode and re-encode the data as a
> single strip?  All the tests that I've attempted seem to indicate that
> the answer is no, but I fail to understand why.
> 
> What I was trying to do is create a postscript file that does the
> following (all TIFFs are planar configuration, multi-strip G4 files):
> 
> {
>   nstrips {
>     ncols rowsperstrip g4image
>     0 offset translate
>   } repeat
> }
> %%BeginData
> exec
> [ all data, encoded as ASCII85 G4 stream ]
> 
> nstrips = number of strips in the TIFF file,
> ncols = image width
> g4image = procedure that renderes g4-encoded data stream
> offset = height of rendered image strip on the page
> 
> This doesn't seem to work reliably for all TIFFs (at least with the
> code that I wrote).  Isn't it the case that a G4 TIFF strip is
> fundamentally equivalent to a G4 image and therefore I should be able
> to use the same Postscript code to render it?
> Does any TIFF/postscript/PDF guru have any insight?
> 
> -- Alberto

With an image made up of strips, it is relatively easy when using the
dictionary version
of the image operator. The basic idea is to use a procedure as data
source that interprets
the image data as a sequence of subfiles using 
strip_bytecount () /SubFileDecode filter
for each strip. The other image dict entries are simply set up for the
image as a whole.

With tiled images, it is a bit more complicated - tiles images must be
processed as a
sequence of distinct images, where I'ds suggest not to do scale and
translate the tiles
separately but rahter defining the position of the tiles using the image
matrix. That's
do avoid rounding errors - the image matrix deals with the image
coordinate system, which
uses pixels as unit.

If I totally disturbed your mind, drop me a note, I'll hack you a sketch
then.

Helge

-- 
H.Blischke@srz-berlin.de
H.Blischke@srz-berlin.com
H.Blischke@acm.org
