| Joe,
As a workaround, you can correct the alignment in the table
by using two successive dashes instead of one dash. This will
produce an endash for all devices, and will eliminate the
skewing caused by the misbehaving hyphen in PostScript output.
Gotta dash, Lee
|
| Yup, the problem is in the hyphen-that-comes-out-as-an-endash. In
DEC Multinational Character Set, character 45 (decimal) is called
"minus". This term dates from VT100s, etc., where minus and hyphen
are interchangeable terms.
But in the proportional spaced world of PostScript, minus is the
thing you use with numerals (which are often an "en" wide), so "minus"
gets you an endash. What you wanted here was a hyphen, and what
TeX counted was the width of a hyphen -- but PostScript was ultimately
told to put out a different character, "minus", which is wider.
This means what is printed is slightly different from what the
formatter asked for.
The problem will be fixed in the next version. In the meantime,
if you don't want to code each row of the table as a separate row,
Lee's workaround in .2 will at least get you sensible output, even
though it's not perfect.
FYI: As it happens the same problem occurs with hyphens used for
line breaks. So if you see a PostScript line hanging out
in the margin, but get no line-too-long errors, see if the line
contains these "long hyphens".
--Mark
|
| > The problem will be fixed in the next version.
(My, they're building versions closer and closer together.)
For the fix you need, copy from VAXUUM or CLOSET this file:
KITS_:[DOCUMENT.V10]DVC$PROLOG.PS
into your VAX DOCUMENT directory identified by the logical:
DOC$PS_FONTS
This will cause the PostScript files you create from then on to
print out the skinny hyphen whenever you enter a single hyphen ('-')
into your source file; this is also the hyphen you'll get when
words are hyphenated. Thus the PostScript behavior will be consistent
with that of the LN03 support.
--Mark
|