14

When I \includegraphics certain PDF files (for example this SVG converted with Inkscape), the output produced by LuaLaTeX or PDFLaTeX will be such that when the page containing the picture is printed with CUPS, the whole page will be rasterized which looks like the bottom example in the picture below (I have the CUPS option to "force rasterization" which produces the same bad printout with any page so CUPS or my configuration of it is surely partly to blame). The first line is the same page without that PDF included. Other PDFs work just fine, as do all raster images (which is kind of paradoxical).

comparison of scans of printed text

These are scans of the result of course, so please excuse the bad quality. You should still be able to see the wavy look of the "l"s and other slanted vertical lines.

Here for a comparison the rasterized output as a PDF:

pdf rendering

I experimented a bit with different PDF viewers and printing to PDF instead of wasting paper. Here is what okular produced:

okular output

And this is acroread at the same zoom level:

acroread output

If you watch closely, acroread might just have a slight edge ;)

Even when forcing acroread to "print as image" as I suppose the "force rasterization" option is named here, the result looks much better:

acroread output when forcing image

I don't know if it looks like the insane 2400 dpi it's supposed to be but still (these pictures are printed at about the text size of \small) .

| improve this question | |
  • 1
    I love you for asking this question, stackexchange for hosting so many nice FAQs and @Daniel for providing a helpful answer. I already thought I was the first perfectionist to notice this buggy behavior. If the driver would at least have used more DPI for printing. But I guess it only really is visible on a laser printer. – mxmlnkn Apr 12 '18 at 17:34
9

This is most probably caused by transparency effects. Transparency effects are a relatively new feature for PDF (≥ 1.4) and many printers do not yet support it "out of the box" (basically, this requires a PostScript Level 3 RIP with additional PDF 1.4 extensions). So the printing system (printer driver) has to "flatten" transparency effects by rasterizing objects into ordinary CMYK objects before sending them to the printer.

Rasterizing is usually done page-wise: The complete page is rasterized into a bitmap and then send to the printer. This also effects the other content of the page, resulting in the observed "coarse appearance" of the text.

Especially, but not only, on Linux, many printer drivers do not do a particularly good job here. This is the reason that the results are often better when printing from Adobe Reader, which (optionally) perform the flattening before sending the page to the printer driver.

Workaround

The way out would be to flatten transparency effects in PDF graphics before embedding them into the document, so that the printer driver has no reason to rasterize a whole page. Adobe provides a white paper with some background info and how to achieve this with their products. My approach would be to use ghostscript to convert the respective images to PDF 1.3, which does not support transparency effects, hence, enforces their rasterization:

ps2pdf13 image.pdf image-13.pdf

Unfortunately, ghostscript also just rasterizes the complete page (image), so the fonts inside the image will still get the "coarse appearance" and their text is no longer selectable in the resulting PDF. However, the main text of the document will now keep its high printing quality.

The situation becomes a bit different, if the transparency or shading effects on a page are not caused by an included graphics, but generated with pdflatex directly – for instance, by using TikZ. The solution in the TiKZ case would be to employ its externalization feature to automatically perform the above transformation during compilation. There has been a dedicated question for this problem here on tex.se.

| improve this answer | |
  • Thanks, that's very enlightening! Acroread seems to be able to do a flattening that keeps the vector properties of the image (see above). As for manual rasterization of the image, I think I'd prefer generating a png with whatever tool does the best job. Somehow I don't like PDF as a raster format. I can also not control the resolution in the commandline above. – Christian Sep 11 '12 at 7:54
  • @Christian: I would refrain from that and my strategy is exactly the opposite: PNG processing by pdflatex is actually quite limited and can lead to sigificantly higher compilation times. For this reasons I usually convert all PNG images to PDF. – Daniel Sep 11 '12 at 11:35
  • the possible improvements seem indeed dramatic. I changed my workflow to include PDFs instead of PNGs. However, PNG is still the format I work with. Converting to PDF is just a kind of preprocessing step for me. I still don't trust and don't understand it sufficiently as a raster format ;) So now there are PDF originals that are rastered to PNG and then converted to PDF. Call me queer ;) – Christian Oct 11 '12 at 0:06
  • Some things from my Odyssey. You can check PDF versions with exiftool or pdfinfo. Version 1.4 or 1.5 don't pose a problem per se, only if they use transparency. My tansparency issues came from matplotlib. Beware of transparent legend backgrounds, i.e., legend( ..., framealpha=0.5) and other plot commands plot( ..., alpha=0.5). plot_surface is transp. by default! Use plot_surface( ..., alpha=1) to turn that off. The Axes3D backgrounds are also transparent. Turn that off with gray=(0.95,0.95,0.95,1); ax3d.w_xaxis.set_pane_color(gray); (repeat for w_yaxis and w_zaxis). – mxmlnkn Apr 12 '18 at 18:55
  • In order to get rid of alpha channels in included PNGs, do: for file in *.png; do channel=$( identify -format '%[channels]' -- "$file" ); if [ -n "$channel" ] && [ -z "${channel//*a*/}" ]; then convert "$file" -background white -alpha remove -alpha off "$file"; fi; done – mxmlnkn Apr 12 '18 at 19:58
4

A reason could be that the included PDF file contains transparency effects that are not available in PostScript. Thus the rasterization could be just a workaround to implement transparency.

| improve this answer | |
  • That sounds reasonable although there is at least one file I created in Inkscape that makes use of alpha blending as well and whose page didn't look bad. I will check if the presence of a white background makes any difference. In any case, is there an easy way to batch-check PDF files for transparency so that I know what files to pre-render or fix in any other way? – Christian Sep 10 '12 at 20:20
  • I had a hunch that maybe PDFs with transparent backgrounds were the problem. I changed the background of the PDF above from transparent to white and nothing changed. Just for the record :/ – Christian Sep 11 '12 at 0:45
4

I had this problem with both Acrobat and Evince but more often with Evince for some reason. I am not sure about the causes, but typically the problem involved raster graphics with transparencies or certain symbols/fonts.

The only workaround I found was to set the raster resolution to the maximum possible in the printer setting, for example 1200 dpi if it is available. This gives almost the same result as a proper vector image. Printing times can increase. These options are available in the usual printing dialogues.

Also make sure that you set the proper driver for the printer so you can exploit the maximum resolutions that is available.

print options evince

| improve this answer | |
  • I'm pretty sure that the driver is correct and I tried four different printers with no difference whatsoever. I didn't try acroread though which I will. I didn't find any option to change the rasterization resolution. It's one of the things I don't understand: why a lower resolution is used in the first place. – Christian Sep 10 '12 at 22:19
  • Adobe Reader indeed has a far better print dialog and has the option to choose the rasterization level. Up to 2400 dpi in fact. I just don't know what for though since even the problematic pages are output as vector graphics. So I guess just printing from acroread might solve my problems for now. – Christian Sep 11 '12 at 0:47
  • @Christian, see the screenshot in my edit, you can set it from Evince printing options or set it permanently from printer options. – alfC Sep 11 '12 at 1:15
  • Yeah, I had found it in evince but not in okular and now I know why: its presence depends on the printer. The CUPS PDF printer has this option, the actual laser printers don't. What is even more astonishing though is the fact that printing at 2400 dpi into a PDF page doesn't look any less crappy than what I showed above. It clearly doesn't look like anywhere near 2400 dpi to me. – Christian Sep 11 '12 at 1:28
  • Try to put it as a global setting (upper windows in the screenshot). Settings -> Printing -> printer -> properties -> Printer Options -> Print Quality: 1200 dpi. Also I am not sure if the dpi option in the PDF printer has any meaning, since behind the scenes it is going through postscript conversions, etc. – alfC Sep 11 '12 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.