- 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.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: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.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
- 2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
- 2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
- 2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
- 2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
All,
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 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.
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?
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.
Any ideas?
Richard Nolde