[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: lout->ps->gs2pdf->pdf font problem
From: |
ahoward |
Subject: |
RE: lout->ps->gs2pdf->pdf font problem |
Date: |
Thu, 11 Apr 2002 10:58:47 -0400 |
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