2010.09.27 14:06 "Re: [Tiff] Undocumented options and behaviors in tiff2ps", by Richard Nolde

On 09/25/2010 11:57 PM, Lee Howard wrote:

I've found a few more things to patch in tiff2ps today and made some updates to the man page, pending the acceptance of the new code uploaded to Bugzilla yesterday, to which there has been no response. Rather than post another revision, I'll await a response before sending a new copy. I only have a short time left that I can devote to tiff2ps before I have to move on to other things.

Today was the first time that I had to review and test the code provided on Bugzilla, and I've committed it to CVS. (You probably got a notice from Bugzilla.)

I have not yet seen the other changes of what you speak. I would appreciate a patch (you can make it with 'diff -u') against current CVS rather than a copy of the new tiff2ps.c... it saves me the step of making the patch myself and avoids the risk that some other tiff2ps.c change that goes on between now and then gets undone when preparing the patch myself.

I've been out of town for ten days hiking in the Wind River Range of Wyoming. I'll try to get you some new diffs (they are minor and don't affect functionality for the most part (just a warning instead of an error for failure to specify height and width with the auto rotate option if I remember correctly) today plus a new man page to match the current options. I'm still building a tiffgen utility that can be used to build images of various geometric patterns so that I can test large files on my AIX development platform with CVS head since I don't have a 64 bit Linux box myself.

Richard

Besides documenting the command line options that were missing from the man page, I've tried to add short explanations to some of the existing options and a short note about image placement before the examples section of the man page. In some cases, there is no clear evidence for how various options are intended to interact and many times options are ignored or turned off silently. In other cases, there may be a viable use for an option in a case that is not supported or behaves differently in combination with other options.

For example, with the simple case of converting a TIFF image to Postscript or EPS, with or without a rotation, but not specifying any page size or viewport height/width, what should happen if the user also specifies a left or bottom offset with -l or -b?

A warning message. (?) And then ignore the options, if that's an appropriate thing to do.

The existing man page says that these options do not affect the height or width of the printed image. Is the image then shifted over by that amount and the opposing edge shortened by that amount or should the printed page be extended by that amount to accommodate the extra margin. Since this is a Postscript translate operation, in both the original and current code, the first is what actually happens. On the other hand, if a page size is specified with -h and -w, the image is scaled to allow for the margin. In both cases, negative offsets can be used to crop off portions of the image, though at the expense of introducing an equal sized blank area on the opposite side of the printed page.