Longrightarrow PDF printing good and bad

[Jussi Piitulainen]

I'm worrying about the appearance of \Longrightarrow in a certain
document when printed. Experimenting with pdflatex and this:

\documentclass{article}
\usepackage{amsmath}
\begin{document}
Sorsa \ensuremath{\Longrightarrow} Maali
\end{document}

Two different TeX installations (one Web2C, one TeX Live 2009/Debian)
produce a perfect result on a cheap Samsung laser printer.

In another location, on a HP LaserJet, I get printed arrows that are
visibly made of two parts, a slightly thinner equals sign and a
thicker short arrow.

The compilations of the good arrows I see now report these fonts:

{/usr/share/texmf/dvips/tetex/bbad153f.enc}
</usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb>
{/usr/share/texmf/dvips/tetex/f7b6d320.enc}
</usr/share/texmf/fonts/type1/bluesky/cm/cmr10.pfb>

</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr10.pfb>
</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb>

I don't have access to the same information about the failing arrows
at the moment, but they do come from a relatively recent TeX from the
Ubuntu repositories. I experimented with \usepackage{lmodern} and some
such but nothing changed.

The original PDF with this problem was mailed to me. I don't know on
what platform it was made. In all four cases, pdffonts reports
CM-fonts, Type 1.

Question: Can this depend on the printer? Is the HP printer somehow
the problem?

Some google hits only suggest that this happens to CM at sizes other
than 10pt, but I'm seeing it at 10pt.

[Dan]

On Oct 17, 8:39 am, Jussi Piitulainen <jpiit...@ling.helsinki.fi>
wrote:

> I'm worrying about the appearance of \Longrightarrow in a certain
> document when printed. Experimenting with pdflatex and this:
>
> \documentclass{article}
> \usepackage{amsmath}
> \begin{document}
> Sorsa \ensuremath{\Longrightarrow} Maali
> \end{document}
>
> Two different TeX installations (one Web2C, one TeX Live 2009/Debian)
> produce a perfect result on a cheap Samsung laser printer.
>
> In another location, on a HP LaserJet, I get printed arrows that are
> visibly made of two parts, a slightly thinner equals sign and a
> thicker short arrow.
>
> The compilations of the good arrows I see now report these fonts:
>
> {/usr/share/texmf/dvips/tetex/bbad153f.enc}
> </usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb>
> {/usr/share/texmf/dvips/tetex/f7b6d320.enc}
> </usr/share/texmf/fonts/type1/bluesky/cm/cmr10.pfb>
>

(1) This is ancient configuration. Nowadays the encoding files should
be in
/usr/share/texmf/fonts/enc/dvips/tetex/ and the type1/bluesky
directory is gone, all
the fonts being moved to type1/public/amsfonts/ now.

(2) My pdflatex doesn't report encoding files at all.

(3) There were some changes in the type 1 cm fonts several years ago
(after the above mentioned change in the encoding directory, but
contemporaneous with the removal of the bluesky directory). I don't
know whether the \Rightarrow or equal sign was changed. (Those are
the
characters joined to make a \Longrightarrow.)

> </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr10.pfb>
> </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb>

This is how it should look.

> but they do come from a relatively recent TeX from the
> Ubuntu repositories. I experimented with \usepackage{lmodern} and some
> such but nothing changed.

I think older lmodern still used cm for the math bits.
I'm guessing your "relatively recent TeX" is maybe not all
that recent.

>
> The original PDF with this problem was mailed to me. I don't know on
> what platform it was made. In all four cases, pdffonts reports
> CM-fonts, Type 1.
>
> Question: Can this depend on the printer? Is the HP printer somehow
> the problem?

There used to be problems long ago (at least a decade) with TeX-
generated
PDF and HP printers, but I don't remember it involving arrows. ISTR
the
tall parentheses and the integrals being affected.


Dan

[Jussi Piitulainen]

Dan writes:

> On Oct 17, 8:39 am, Jussi Piitulainen wrote:
> > I'm worrying about the appearance of \Longrightarrow in a certain
> > document when printed. Experimenting with pdflatex and this:
> >
> > \documentclass{article}
> > \usepackage{amsmath}
> > \begin{document}
> > Sorsa \ensuremath{\Longrightarrow} Maali
> > \end{document}
> >
> > Two different TeX installations (one Web2C, one TeX Live 2009/Debian)
> > produce a perfect result on a cheap Samsung laser printer.
> >
> > In another location, on a HP LaserJet, I get printed arrows that are
> > visibly made of two parts, a slightly thinner equals sign and a
> > thicker short arrow.
> >
> > The compilations of the good arrows I see now report these fonts:
> >
> > {/usr/share/texmf/dvips/tetex/bbad153f.enc}
> > </usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb>
> > {/usr/share/texmf/dvips/tetex/f7b6d320.enc}
> > </usr/share/texmf/fonts/type1/bluesky/cm/cmr10.pfb>
>
> (1) This is ancient configuration. Nowadays the encoding files should
> be in
> /usr/share/texmf/fonts/enc/dvips/tetex/ and the type1/bluesky
> directory is gone, all
> the fonts being moved to type1/public/amsfonts/ now.

Yes. My impression is that the administrators are not too keen to keep
that server up-to-date. I used it in this experiment because it was
different from the other two.

> (2) My pdflatex doesn't report encoding files at all.
>
> (3) There were some changes in the type 1 cm fonts several years ago
> (after the above mentioned change in the encoding directory, but
> contemporaneous with the removal of the bluesky directory). I don't
> know whether the \Rightarrow or equal sign was changed. (Those are
> the characters joined to make a \Longrightarrow.)
>
> > </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr10.pfb>
> > </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb>
>
> This is how it should look.
>
> > but they do come from a relatively recent TeX from the Ubuntu
> > repositories. I experimented with \usepackage{lmodern} and some
> > such but nothing changed.
>
> I think older lmodern still used cm for the math bits.
> I'm guessing your "relatively recent TeX" is maybe not all
> that recent.

It turned out to be TeX Live 2009/Debian - same as one of the two
systems I originally reported above.

I have now tested the files both ways. This morning I downloaded one
of the PDF files that printed correctly on the Samsung printer on
Monday, and uploaded one that printed badly on the HP. The results:

PDF made somewhere else
- prints badly on the HP.

PDF made on the ancient Web2C TeX
- prints cleanly on the Samsung,
- prints badly on the HP.

PDF made on TeX Live 2009/Debian
- prints cleanly on the Samsung,
- prints badly on the HP.

So it seems to depend only on the printer. The same PDF file prints
differently on the two printers. The HP (a LaserJet model, something
like p2055nd) is a Postscript printer. The cheaper Samsung is not.
That may or may not be relevant.

> > The original PDF with this problem was mailed to me. I don't know on
> > what platform it was made. In all four cases, pdffonts reports
> > CM-fonts, Type 1.
> >
> > Question: Can this depend on the printer? Is the HP printer somehow
> > the problem?
>
> There used to be problems long ago (at least a decade) with TeX-
> generated PDF and HP printers, but I don't remember it involving
> arrows. ISTR the tall parentheses and the integrals being affected.

The printer is certainly less than a decade old. Google has not given
me anything relevant.

I can live with this myself, and I will not bother the authors of the
document in question. They probably wouldn't even see the problem.

It is unusual and disappointing that TeX manages to look bad in the
area of mathematical symbols. Thankfully it's not widespread, again
judging from the lack of response from Google.

Dan, thank you for your advice.

[Dan Luecking]

On 19 Oct 2011 17:28:41 +0300, Jussi Piitulainen

Still, there are directories that weren't in TeXLive 2009, so
it would seem there are vestiges of an even older installation
of TeX. This cannot be the actual problem since the printing of
a file prepared elsewhere also fails, but it can lead to other
problems. If nothing else it makes the statement "prepared with
TeX Live 2009" uncertain.

>
>So it seems to depend only on the printer. The same PDF file prints
>differently on the two printers. The HP (a LaserJet model, something
>like p2055nd) is a Postscript printer. The cheaper Samsung is not.
>That may or may not be relevant.

A quick google showed a number of bug reports for this printer
and/or its driver (though not this particular bug). Some drivers
were reportedly patched in response. Perhaps an upgrade of the
printer drivers could help. (Some of the bug discussions also
mention a firmware upgrade.) If GhostScript is part of the print
process, it's version might be relevant also.


Dan
To reply by email, change LookInSig to luecking

[Jussi Piitulainen]

Dan Luecking writes:
> On 19 Oct 2011 17:28:41 +0300, Jussi Piitulainen wrote:
> > Dan writes:
...

> >> (3) There were some changes in the type 1 cm fonts several years
> >> ago (after the above mentioned change in the encoding directory,
> >> but contemporaneous with the removal of the bluesky directory). I
> >> don't know whether the \Rightarrow or equal sign was changed.
> >> (Those are the characters joined to make a \Longrightarrow.)
> >>
> >> > </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr10.pfb>
> >> > </usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb>
> >>
> >> This is how it should look.
> >>
> >> > but they do come from a relatively recent TeX from the Ubuntu
> >> > repositories. I experimented with \usepackage{lmodern} and some
> >> > such but nothing changed.
> >>
> >> I think older lmodern still used cm for the math bits.
> >> I'm guessing your "relatively recent TeX" is maybe not all
> >> that recent.
> >
> > It turned out to be TeX Live 2009/Debian - same as one of the two
> > systems I originally reported above.
>
> Still, there are directories that weren't in TeXLive 2009, so
> it would seem there are vestiges of an even older installation
> of TeX. This cannot be the actual problem since the printing of
> a file prepared elsewhere also fails, but it can lead to other
> problems. If nothing else it makes the statement "prepared with
> TeX Live 2009" uncertain.

True. These come from Ubuntu repositories where they have, I think,
repackaged TeX Live in some way. I won't spend time on this now, since
the problem appears to be elsewhere.

> > So it seems to depend only on the printer. The same PDF file
> > prints differently on the two printers. The HP (a LaserJet model,
> > something like p2055nd) is a Postscript printer. The cheaper
> > Samsung is not. That may or may not be relevant.
>
> A quick google showed a number of bug reports for this printer
> and/or its driver (though not this particular bug). Some drivers
> were reportedly patched in response. Perhaps an upgrade of the
> printer drivers could help. (Some of the bug discussions also
> mention a firmware upgrade.) If GhostScript is part of the print
> process, it's version might be relevant also.

Thanks. I can check later if using another computer (Mac OS X and
possibly different printer drivers) makes a difference. So far I've
printed everything from a PDF viewer called Evince; I don't know if it
uses Ghostscript.

[Robin Fairbairns]

Jussi Piitulainen <jpii...@ling.helsinki.fi> writes:

> Thanks. I can check later if using another computer (Mac OS X and
> possibly different printer drivers) makes a difference. So far I've
> printed everything from a PDF viewer called Evince; I don't know if it
> uses Ghostscript.

evince doesn't have a good reputation here: we (sys-admins) regularly
get complaints of documents that won't print, and it often turns out
that evince is the problem. it produces terrible postscript that
crashes one of our smaller printers; printing the same document through
acrocr*p doesn't have the same problem.

of course, printers shouldn't crash, but if bloatware from adobe can
produce compact enough postscript, what does it say for evince?
--
Robin Fairbairns, Cambridge
my address is @cl.cam.ac.uk, regardless of the header. sorry about that.

[William F Hammond]

Robin Fairbairns <rf...@cl.cam.ac.uk> writes:

> evince doesn't have a good reputation here: we (sys-admins) regularly
> get complaints of documents that won't print, and it often turns out
> that evince is the problem. it produces terrible postscript that
> crashes one of our smaller printers; printing the same document through
> acrocr*p doesn't have the same problem.

Is your experience with xpdf happier?

-- Bill

[Robin Fairbairns]

personally, yes. however, i don't think i've any significant data
points apart from my own experience, and my "local" printers are the lab
workhorses -- big expensive machines with frightening throughput (so
that there's little likelihood of a printer being overfaced with my
output; note that i don't use evince except when some other app has
opened it for me, unasked).

[Donald Arseneau]

Robin Fairbairns <rf...@cl.cam.ac.uk> writes:

> evince doesn't have a good reputation here: we (sys-admins) regularly
> get complaints of documents that won't print, and it often turns out
> that evince is the problem. it produces terrible postscript that
> crashes one of our smaller printers; printing the same document through
> acrocr*p doesn't have the same problem.

Evince also renders badly when there is overlapping "ink" as is the
case for the long arrows: the overlap portion displays blacker.
It seems as if evince does anti-aliasing of characters separately
before combining them on the page/screen.

For example, if a character fills a particular pixel 50%, then
over-printing a duplicate character makes that pixel 75% black
(or there-abouts).

Maybe it is a "feature" to better emulate typewriters equipped with
fabric ribbon.


Donald Arseneau as...@triumf.ca

[Jussi Piitulainen]

Donald Arseneau writes:

> Robin Fairbairns writes:
>
> > evince doesn't have a good reputation here: we (sys-admins) regularly
> > get complaints of documents that won't print, and it often turns out
> > that evince is the problem. it produces terrible postscript that
> > crashes one of our smaller printers; printing the same document through
> > acrocr*p doesn't have the same problem.
>
> Evince also renders badly when there is overlapping "ink" as is the
> case for the long arrows: the overlap portion displays blacker.
> It seems as if evince does anti-aliasing of characters separately
> before combining them on the page/screen.

Yes, I see that in my Longrightarrows in evince. It bothers me far
less than the bad printing.

[Jussi Piitulainen]

Robin Fairbairns writes:

> Jussi Piitulainen writes:
>
> > Thanks. I can check later if using another computer (Mac OS X and
> > possibly different printer drivers) makes a difference. So far I've
> > printed everything from a PDF viewer called Evince; I don't know if it
> > uses Ghostscript.
>
> evince doesn't have a good reputation here: we (sys-admins) regularly
> get complaints of documents that won't print, and it often turns out
> that evince is the problem. it produces terrible postscript that
> crashes one of our smaller printers; printing the same document through
> acrocr*p doesn't have the same problem.

Another moving part. I've been happy with evince as a viewer. I don't
seem to have any other viewers installed.

I tried with lpr on the command line and it produced the same broken
Longrightarrows: thinner slightly displaced equals-sign connected to a
short arrow.

Then I tried pdf2ps (from ghostscript 8.71) and then lpr. That
produced good arrows.

$ pdflatex arrow ; lpr arrow.pdf (broken)
$ pdf2ps arrow.pdf ; lpr arrow.ps (whole)

However, the print quality suffered in general. The font looked
thinner and many shapes had small gaps. This is meant for some higher
quality device? Also, when I translate back to PDF with ps2pdf,
pdffonts does not find any fonts in the resulting file and evince
cannot select text by mouse. Does the translation to postscript always
do this?

Now I wonder what lpr (CUPS?) does when it prints PDF. Most likely
I'll just live with the problem.

> of course, printers shouldn't crash, but if bloatware from adobe can
> produce compact enough postscript, what does it say for evince?

I'm not sure.