4

I used this answer to make nicer looking links (dark colors instead of hideous boxes). It works nicely, but what I liked about the default setup with boxes, is that the printed text would be completely black. Is it possible to setup hyperref (or LaTeX in general) to have colored links when PDF is veiwed on screen but black text when printed?

Hennadii Madan
  • 259
  • Option ocgcolorlinks does it. – AlexG Apr 24 '18 at 15:19
  • If you don't mind having different PDF files for printing and on-screen viewing, this message could maybe help you. – frougon Apr 24 '18 at 21:41
  • @frougon, thanks, but that's such an overkill, same result can be achieved by having two versions of options to hyperref in my case. I am reluctant to do even that, that's why I asked. – Hennadii Madan Apr 26 '18 at 08:49
  • Sure, but in order to switch between the two versions of options, you need either to modify your .tex file every time you want to switch, or to implement automatic switching via some conditional processing in the .tex file. The approach I linked to implements the latter, so that you can produce your various versions automatically (by running 'make', a simple script, whatever) without touching your .tex file once things have been set up. But if it's overkill, no problem, no one forces you to use it. :) – frougon Apr 26 '18 at 18:30

1 Answers1

3

This is possible using PDF Layers, officially named Optional Content Groups (OCG). The coloured link text is put on a layer that is only visible in the PDF viewer, while the same link text in the colour of the surrounding text (usually black) is put on a layer that is only for print.

However, only a few PDF viewers respect these visibility settings for screen/printing: Acrobat (Reader), Foxit, possibly PDF-XChange, the Chrome/Chromium-builtin PDF viewer.

Package hyperref provides option ocgcolorlinks for this. But it has one major issue: longer links don't wrap around line breaks and page breaks. Moreover, it is incompatible with PDF-Layer making packages.

Package ocgx2 tries to solve both issues:

\usepackage{hyperref} %don't use ocgcolorlinks here
\usepackage[ocgcolorlinks]{ocgx2}
AlexG
  • 54,894
  • I didn't realize that LaTeX could do OCG. Learned something new. Although it is very unlikely that anyone interested in the subject would have this issue, I should mention: If you are creating a book that will have a print version and a digital PDF version, it seems that OCG is helpful. However, many commercial printers still require that PDF files not exceed PDF 1.4, which excludes OCG. I imagine that the reason for the technology lag, is that the installed base of printing machines has a very long lifetime, despite firmware updates. –  Apr 24 '18 at 15:04
  • This feature is meant for printing from within a PDF viewer. I think commercial printers still prefer Postscript, which they get from the PDF viewer directly or via a printer driver. – AlexG Apr 24 '18 at 15:10
  • I refer to the print-on-demand market. The printers always request PDF (a few accept MS Word, which they convert for a fee). Many of them require PDF/X-1a or X-3. Never X-4 (not yet, that is). I do not know of any who will accept PostScript submissions. The printing machine may well transform PDF to PostScript internally, but I suspect that is not done by the machines used for P.O.D. –  Apr 24 '18 at 17:05
  • Didn't test yet, but I get a hunch that it's as good as it can get. Accepted. – Hennadii Madan Apr 26 '18 at 08:50
  • Will simply loading that package handle the link colours? I set some colours manually and even in the print preview, email addressess etc are in those colours. Will they be changed to black in the final printing process? – Manuel Popp Sep 28 '21 at 01:27
  • 1
    Yes, as written in the answer. I ran a test with the current ocgx2 v. 0.53, 2021/06/16, and pdflatex. Chrome's PDF plugin shows links in black in the print preview. Would you please verify the package version you are using? – AlexG Sep 28 '21 at 09:53
  • Just tested it in Chrome, the colours in the print preview appear to have been due to my version of Firefox, not a property of the pdf – Manuel Popp Sep 28 '21 at 12:31