| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2010.09.27 14:06 "Re: Undocumented options and behaviors in tiff2ps", by Richard NoldeOn 09/25/2010 11:57 PM, Lee Howard wrote: > Richard Nolde 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. > > Thanks, > > Lee. > |
|||||||