AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2010.07.08 16:25 "[Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.08 18:03 "Re: [Tiff] strlcpy vs strncpy", by Lee Howard
2010.07.08 18:06 "Re: [Tiff] strlcpy vs strncpy", by Olivier Paquet
2010.07.11 17:36 "Re: [Tiff] strlcpy vs strncpy", by Edward Lam
2010.07.12 19:30 "[Tiff] strncpy in tiffcrop", by Richard Nolde
2010.07.12 20:31 "Re: [Tiff] strncpy in tiffcrop", by Edward Lam
2010.08.06 18:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Toby Thain
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 15:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.06 15:57 "Re: [Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 16:24 "Re: [Tiff] tiff4 on 32-bit Windows", by Edward Lam
2010.08.06 16:51 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.06 16:38 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.09 12:59 "Re: [Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 15:37 "Re: [Tiff] tiff4 on 32-bit Windows", by Olivier Paquet
2010.08.07 06:34 "[Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Andreas Kleinert
2010.08.07 06:36 "Re: [Tiff] tiffcp crashes on tile to strip conversion for < 8 bit", by Andreas Kleinert
2010.08.15 04:45 "Re: [Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Lee Howard
2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.10 13:27 "Re: [Tiff] strlcpy vs strncpy", by Kevin Myers
2010.07.10 13:50 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 07:34 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.11 08:06 "Re: [Tiff] strlcpy vs strncpy", by Toby Thain
2010.07.11 14:35 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.10 13:39 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 08:18 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.11 16:35 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
2010.07.12 18:13 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
2010.08.02 19:25 "[Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
2010.08.02 19:34 "Re: [Tiff] BigTIFF Support in LibTiff", by Bob Friesenhahn
2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
2010.08.23 04:54 "Re: [Tiff] tiff2ps page sizing options", by Lee Howard

2010.08.23 04:54 "Re: [Tiff] tiff2ps page sizing options", by Lee Howard

     I'm revisiting tiff2ps to fix a bug with images that have no
resolution unit tag but do have x and y resolutions. That fix seems to
be only a line or two but while I'm back in the code, I'm trying to
clean up a few things in my patches so they can be resubmitted once more
for inclusion in at least some version of libtiff. The current CVS
version has some of my work from 2005 that allows for additional
rotations of 90 and 270 degrees and page chopping by width as well as
height. However, there are known bugs in it that were fixed in
subsequent patches that never got applied in CVS. I'm trying to
simplify the old code and my patches before making any new submissions.
There are also errors in the current man page that I can address.

I'll be happy to review your work when you're done.

I have some questions about how tiff2ps worked originally and/or should work when multiple options are specified. In particular, there isn't a clear definition of how the -H, -W, -h -w flags interact when they are combined. I think that -h and -w define the size of the page on which the image is presented whereas -H and -W define viewports into the image that will be output. In other words, -H or -W could be used to specify that only a portion of the image be displayed on a given output page, with additional pages created to handle the overflow. To me, this implies that -H can never be larger than -h, -W can never be larger than -w.

I'm not an authority as I didn't author the -H/-W/-h/-w options, and I don't use those features, but the way that I read the man page documentation (which was written by the options author, I suspect) it appears that -h and -w refer to the printed area of the image. They define the page size. In other words, I may want to resize the image to only be 4x5" area on the page, and I'd do this with the -h and -w options without the use of the -H and -W options.

The -H and -W options appear to be ways to print the image on multiple pages without resizing if the image does not fit within the page boundaries defined by -h and -w.

Correct, my reading is that -H is never larger than -h and -W is never larger than -w.

If -h and -w are specified alone, the entire image is scaled to fit on that size output media. If -H is also specified, the image is scaled to the -w value (or native width if no -w is specified) horizontally and the result clipped to -H in each page that is required. If -W is specified with -h and -w, the image is scaled to the -h value (or native height if no -h is specified), and the result clipped to -W in each page that is required. Yes/No?

This sounds correct to me.

If -H or -W are specified without -h and -w, I assume no scaling should take place, only clipping and generation of multiple pages as needed.

This also sounds correct.

Thanks,

Lee.