RE: lout->ps->gs2pdf->pdf font problem

[ahoward]

All,

Sorry for not enough detail.  In the course of gathering all the detail
and trying to answer some of your questions, I stumbled upon something.

First, I'll give you some background detail:

I had thought this was specifically a font problem.  The font in 
question
is Trebuchet MS (TTF) converted to ATM Type 1 as indicated here:

% AUTOMATICALLY Converted from trebuc.ttf by TTF2PS from BaKoMa TeX

I now know, this is NOT REALLY a font problem.  It is a TABLE problem.

I had thought clipping only happened on the BOLD version of this font.

I now know this will happen to non-bold text also.

If I make a document and just switch fonts, the final PDF prints just 
fine.  
It is not particular to the BOLD fonts at all...BUT, if I put text 
inside 
a TABLE and switch fonts, clipping will occur.

(Most of the text in this document is tabular.  Not that there isn't a 
better 
way, it's just that I'm kinda new to lout and I understand how to 
position 
things where I want them with tables.)

Versions I am running
---------------------
Linux 2.2.14-5.0smp (RH6.2)
AFPL Ghostscript 7.03 (2001-10-20)
Basser Lout Version 3.20 (April 2000)

Documents are produced on linux and final PDFs are for end-users with 
Win32 
systems and Acrobat Reader 4.

When using GSView 4.1 on Win32 to view the PS file created by lout on
linux side, all is fine.  Looks fine on screen, prints OK, no clipping 
of
text.  In or out of tables.

PDF created by ps2pdf on linux _looks_ fine in Acrobat, but prints with 
cropped/clipped fonts in some table cells. 

SAME PDF printed using GSView 4.1 on Win32 _prints fine_!

(This has been really helped me narrow down where the problem is...)

I have not tried to print or view the PS or PDF files from Linux as the 
machine generating them is a production server without lpr or X.

Now, what I have been able to determine from this is the following:

The problem is not necessarily with anything Lout is doing or with
anything ghostscript is doing.  It appears Acrobat is hard-limiting the 
vertical size of rows/cells in tables, which causes cropping of the top 
of some text.

My thinking is that lout puts a vertical strut into the cell at 1.0
times the current base font size.  Now, when I change to a font that is 
larger 
than the vertical strut, GSView and Acrobat render the page for screen 
OK 
because they are adjusting the vertical size of the row/cell so the 
larger font 
will fit.

BUT, while GSView also seems to adjust the size of the row/cell when 
printing,
Acrobat does not.

I am now testing setting different size vertical struts in rows/cells to 
see if
I can get lout to tell Acrobat the size of the cell is big enough.

Please, if anybody has any information that can help me figure this out, 
let me
know.

Thanks again,
-Aaron