Re: [hylafax-users] Attachment offset problem

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.10.02 21:31 J. Piers Hearn wrote:

> Sorry, didn't make the error overally clear. The resulting fax 
> appears as though it has been shifted several centimeters up the 
> page, resulting in the top being cut off. The fax header line still 
> appears as normal at the top. There is no shrinking or other 
> modification of the TIFF.

> I've tried sending the TIFF manually with: sendfax -n -d <number> 
> imagefile.tiff , and I get exactly the same problem. There appears to 
> be no further coversion of the TIFF file, it's sent as is. The TIFF 
> files in docq all appear as expected, no cropping or anything has 
> occurred. The relevent portions of the log follow:

Are you absolutely sure you looked at the *right* docq file?  It will 
only be there after faxq processes it and before it is actually sent.  
So you'll probably need to send it to a "NO ANSWER", "NO CARRIER", or 
"BUSY" destination in order for you to actually see that file *between 
send attempts*.  The filename will be similar to "doc994.ps;c0".  In my 
case I send PostScript files, so yours may look like "doc994.tif;c0" 
since you send TIFFs.

If *this* file looks fine then you're probably complaining about either 
the tagline imaging process or the pagechopping process.  You can turn 
off pagechopping to test for which one is the problem.

The tagline imagine process *intentionally* overwrites the space in 
which it is produced.  Thus, if your TIFF is a full-page of black the 
tagline will delete those black lines and replace it with its own lines.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxxxxx*