AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
September 2010

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

Valid HTML 4.01!


2010.09.08 21:16 "Undocumented options and behaviors in tiff2ps", by Richard Nolde
2010.09.26 05:57 "Re: Undocumented options and behaviors in tiff2ps", by Lee Howard
2010.09.27 14:06 "Re: Undocumented options and behaviors in tiff2ps", by Richard Nolde

2010.09.26 05:57 "Re: Undocumented options and behaviors in tiff2ps", by Lee Howard

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.

> 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.