ps2pdf printing problem: missing minus sign in math
context
I'm having the following problem, I assume with ps2pdf13:
- start with latex. Using times font package
- dvips, using Blue Sky postscript version of CMR fonts.
produces correct .ps, prints ok
- ps2pdf13 produces correct looking pdf viewed on screen, but
** print (from acrobat4) is MISSING all minus signs in the math,
possibly other things missing but that's what I noticed.
- The pdf prints OK if the postscript CMR fonts are not included at the
dvips stage, however,
but then the on-screen view is poor.
I've seen other posts on this, but no answers (or I didn't understand
the answer possibly).
Versions:
redhat linux 6.0 (2.2x kernel), stock latex. Also tried RH7.1 with same
results, but did not test extensively
downloaded new ghostscript 6.50
dvips version 5.86
ps2pdf13 associated with ghostscript6.50
Acrobat4
Thanks for any suggestions.
(I've seen reference to dvips -G* which moves fonts around. I tried
-G0, didn't seem to help.
In the -G#, what does the # mean?)
Olivier Crouzet
did you try inverting the respective positions of -Ppdf and -G0 ? I think
-G0 must be after -Ppdf or it won't work.
Olivier.
--
***************************************************************
Olivier Crouzet
Human and Machine Perception Research Centre
MacKay Institute of Communication and Neuroscience
Department of Life Sciences
Keele University
Keele
ST5 5BG
United Kingdom
*****************************************************************
Giuseppe Bilotta
> - ps2pdf13 produces correct looking pdf viewed on screen, but
> ** print (from acrobat4) is MISSING all minus signs in the math,
> possibly other things missing but that's what I noticed.
I noticed this as well. Not all minus signs are missing always, and
other missing glyphs are vertical bars. Looks like thin lines are not
always rendered by Acrobat, in print.
--
Giuseppe "Oblomov" Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
Louis Vosloo
> context wrote:
> > - ps2pdf13 produces correct looking pdf viewed on screen, but
> > ** print (from acrobat4) is MISSING all minus signs in the math,
> > possibly other things missing but that's what I noticed.
>
> I noticed this as well. Not all minus signs are missing always, and
> other missing glyphs are vertical bars. Looks like thin lines are not
> always rendered by Acrobat, in print.
There are two issues:
(1) Some printer drivers cannot handle control characters (char
code 0--31), in some cases the problems are confined to
character code zero. The glyph "minus" is character code
zero in math symbol encoding.
(2) Some drivers produce "rules" and thin lines in a form that
causes them to drop out at certain magnifictations. This is
particularly true of drivers like DVIPS that produce output that
is not resolution independent and that is "snapped to" an
assumed resolution. This may be either a resolution specified
by the user or the bogus resolution used by Distiller to
prevent such code from failing when distilled.
George N. White III
> Hello,
>
> I'm having the following problem, I assume with ps2pdf13:
> - start with latex. Using times font package
\usepackage{times}? If so, this is outdated and you should
get the current psnfss ver. 8.2 and RTFM.
> - dvips, using Blue Sky postscript version of CMR fonts.
> produces correct .ps, prints ok
> - ps2pdf13 produces correct looking pdf viewed on screen, but
> ** print (from acrobat4) is MISSING all minus signs in the math,
> possibly other things missing but that's what I noticed.
There can be two reasons for this:
1. since TeX encodes math minus as ASCII NUL, some software written with
the std. C library will truncate strings at each math minus, so you may
lose math glyphs that follow the minus
2. some PS rasterizers lose the minus at certain scalings. This occurs
printing A4 documents on US letter paper with "scale to fit" selected in
acrobat reader.
> - The pdf prints OK if the postscript CMR fonts are not included at the
> dvips stage, however,
> but then the on-screen view is poor.
>
> I've seen other posts on this, but no answers (or I didn't understand
> the answer possibly).
Did you use "scale to fit" in the AR4 print dialog? Do you have a PS
printer or are you printing via gs?
> Versions:
> redhat linux 6.0 (2.2x kernel), stock latex. Also tried RH7.1 with same
> results, but did not test extensively
> downloaded new ghostscript 6.50
> dvips version 5.86
> ps2pdf13 associated with ghostscript6.50
> Acrobat4
There have been some significant improvments to the pdf device in gs7.
You should get a recent CVS snapshot such as the one on the xdvi site:
http://www.math.berkeley.edu/~vojta/gsftopk.html
Make sure you have the latest AR4.
> Thanks for any suggestions.
> (I've seen reference to dvips -G* which moves fonts around. I tried
> -G0, didn't seem to help.
> In the -G#, what does the # mean?)
# stands for the 0 or 1 (off or on). The pdf configuration for dvips
has "G1", which means glyphs encoded as ASCII control characters get
remapped. This was necessary for older versions of acrobat reader,
but a) it only works for the BSR CM fonts and b) is not needed with
the current AR4, so you should either edit config.pdf or use
"dvips -Ppdf -G0 ...".
--
George N. White III <gn...@acm.org> Bedford Institute of Oceanography
context
recent postscript printer.
The .ps file prints fine, so it is not an issue of Tex encoding - as ascii
null-
it must be a problem in ps2pdf13 or in acrobat4.
I ran some more experiments using -Ppdf -G0 and the blueskycmr fonts each
on/off.
With -Ppdf, nothing worked.
The .ps appears to print ok regardless of -G0 or not.
I was using dvips -t letter, printing on letter paper, and had 'fit to
page' on most of the time,
but turning it off did not fix it.
I will try the psnfss idea, but my provisional conclusion is that the
postscript CMR
fonts are UNSAFE to use with pdf.
If correct printing depends on e.g. fit-to-page
being set a particular way, or it requires only the most recent version of
acrobat4...
this is not good enough if you want to distribute a .pdf on the web, or
send it to camera ready,
you can't require other people to reliably have particular software and
flags set.
(You can attach a note: "make sure that flag is off", but if they ignore
it, your doc
ends up printed screwey. Too big of a risk).
Dan Luecking
> I neglected to mention the printer- it is a laserjet 6mp, which is a fairly
> recent postscript printer.
>
> The .ps file prints fine, so it is not an issue of Tex encoding - as ascii
> null-
> it must be a problem in ps2pdf13 or in acrobat4.
A few problems were corrected in Acrobat 4.05, is that
what you mean by 4?
>
> I ran some more experiments using -Ppdf -G0 ...
This risks weird effects with ligatures in non-CM
fonts. -G0 is intended exclusively for CM fonts to
try to work around the encoding problems mentioned.
> ...and the blueskycmr fonts each
> on/off.
> With -Ppdf, nothing worked.
> The .ps appears to print ok regardless of -G0 or not.
> I was using dvips -t letter, printing on letter paper, and had 'fit to
> page' on most of the time,
> but turning it off did not fix it.
>
>
> I will try the psnfss idea, but my provisional conclusion is that the
> postscript CMR
> fonts are UNSAFE to use with pdf.
What's really unsafe (I think) is mixing CM type1 fonts with
non-CM type1 fonts. The mathptmx and pslatex packages try to
replace most math with non-cm equivalents. It seems impossible
to get rid of CM entirely, though. (The integral, math
parentheses and bullet seem to always be in CM. The \int and
parentheses I can understand since most ps fonts don't have
the large versions, but the Symbol font appears to have a
perfectly good bullet.)
Did you attempt other methods of producing the pdf, say
pdflatex or dvipdfm? It may be they are craftier about
how CM type1 fonts are encoded/included (or they may not be,
the only way to tell is to try.)
> you can't require other people to reliably have particular software and
> flags set.
> (You can attach a note: "make sure that flag is off", but if they ignore
> it, your doc
> ends up printed screwey. Too big of a risk).
Nevertheless this is done quite a lot do on the web.
It gives people an incentive to upgrade.
Dan Luecking
Giuseppe Bilotta
> (2) Some drivers produce "rules" and thin lines in a form that
> causes them to drop out at certain magnifictations. This is
> particularly true of drivers like DVIPS that produce output that
> is not resolution independent and that is "snapped to" an
> assumed resolution. This may be either a resolution specified
> by the user or the bogus resolution used by Distiller to
> prevent such code from failing when distilled.
Would this mean that pdfTeX-produced PDF shouldn't drop thin lines?
context
I spoke too soon. Yesterday I reported that -G1 fixed the problem. It
did, but it
caused a bigger problem with ligatures(?) - the letter combination 'fi' now
prints as
the English pound sign.
Following one of the posted suggestions, I downloaded the latest acroread
for linux
(called 4.05 in the download, but the help identifies it as 4.0).
With dvips -G0 and ps2pdf, this acroread now prints correctly!
Robin Fairbairns
>I spoke too soon. Yesterday I reported that -G1 fixed the problem. It
>did, but it
>caused a bigger problem with ligatures(?) - the letter combination 'fi' now
>prints as
>the English pound sign.
as expected (given that, iirc, you're using times): see
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=charshift
>Following one of the posted suggestions, I downloaded the latest acroread
>for linux
>(called 4.05 in the download, but the help identifies it as 4.0).
>
>With dvips -G0 and ps2pdf, this acroread now prints correctly!
the problem with this stuff, of course, is you can't trust the rest of
the world not be using the ancient, broken, 4.0. and what's more,
i've had software installations that insist on installing acrobat
reader (on m$ machines, for the documentation) that prove to have
overwritten my 4.05 with 3.0... (this is of course yet another adobe
bug: their installer shouldn't downgrade. however, given other
people's experience with them and the finite nature of life, i can't
be bothered to report it ... i just keep my 4.05 installer sitting on
an "install" share on one of our servers.)
--
Robin Fairbairns, Cambridge
Hans Fr. Nordhaug
Luecking" <luec...@uark.edu> wrote:
> context <con...@jps.net> wrote in message
> news:<3B8BA315...@jps.net>...
[cut]
>> I ran some more experiments using -Ppdf -G0 ...
>
> This risks weird effects with ligatures in non-CM fonts. -G0 is intended
> exclusively for CM fonts to try to work around the encoding problems
> mentioned.
This must be a "typo" by Dan. Doesn't he talk about -G1 ...
--
Hans Fredrik Nordhaug - Ph.D. student at Department of Mathematics,
University of Bergen, Norway