2

I'm trying to submit proposal documents to NSF Fastlane. I'm generating PDF documents using lualatex. My file contains hyperref links internally and externally, but they are removed by Fastlane's upload PDF redistillation. The text remains and is visible, but there is no link to click on.

Here is my minimal non-working example. I compile it using lualatex from the TeXLive 2016 distribution on Windows. The culprit seems to be fontspec. If I remove that line, the links work, but I'd like to use fontspec so I can choose fonts.

\documentclass[fontsize=10pt,paper=letter,twoside=false,onecolumn]{scrartcl} 
\usepackage{fontspec} % This seems to be the problem.
\usepackage{hyperref}
\setmainfont{Palatino Linotype}

\begin{document}
\section{Section}\label{sec}
This is an explicit external url: \url{http://tex.stackexchange.com}.

This is an external link: \href{http://tex.stackexchange.com}{Link}.

This is an internal link to Sec.~\ref{sec}.
\end{document}

My questions are:

  • What about fontspec makes my links get eaten by Fastlane?
  • Is there a workaround?

Edit: The issue is something with how Fastlane handles fonts when it re-distills PDFs.
For example, in the example give, if I run pdffonts on file generated by lualatex I get the following output:

name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
TYJNNQ+PalatinoLinotype-Roman        CID TrueType      yes yes yes     19  0

but after uploading the file to Fastlane and re-downloading, the output of pdffonts gives

name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
EKFDNL+PalatinoLinotype-Roman        CID TrueType      yes yes no      31  0
EKFFKE+PalatinoLinotype-Roman        TrueType          yes yes no      36  0
EKFFNF+PalatinoLinotype-Roman        TrueType          yes yes no       2  0

Somehow the font is being broken up and re-encoded, breaking hyperlinks in the process.

Edit 2: I'm uncertain that the fonts are really the issue. After changing the fonts, \url{} links work, but \href{}{} links still do not.

  • You are not using hyperref in your example, so whatever links you are getting are a result of the pdfviewer heuristic. – Ulrike Fischer Jul 17 '17 at 21:54
  • @UlrikeFischer - Sorry, that was a pasting error. The actual example does have hyperref. Now edited to fix. – Ted Corcovilos Jul 17 '17 at 21:55
  • Don't load fontenc when using lualatex. Does that change anything? I don't recall having this problem, and use fontspec and lualatex also. – Alan Munn Jul 17 '17 at 22:10
  • @AlanMunn - If I remove fontspec then there is no problem. – Ted Corcovilos Jul 17 '17 at 22:11
  • But you shouldn't be loading fontenc. – Alan Munn Jul 17 '17 at 22:12
  • @AlanMunn - Sorry, I misread your comment. fontspec vs. fontenc. However, removing fontenc does not solve the problem. I will edit the example to remove it. – Ted Corcovilos Jul 17 '17 at 22:15
  • You are using different fonts with and without fontspec and it is possible that this changes the distillation process, but imho you can't do much about it. – Ulrike Fischer Jul 17 '17 at 22:15
  • @UlrikeFischer - Do the fonts change if I load fontspec but do not explicitly declare a font? – Ted Corcovilos Jul 17 '17 at 22:17
  • Sure, look at the end of the log-file. It will show you the fonts you include. – Ulrike Fischer Jul 17 '17 at 22:17
  • 1
    @UlrikeFischer - you were right. The fine print on Fastlane says that Type 3 fonts will not work. If I explicitly declare some ttf fonts (e.g. Times New Roman and Courier New), then the distillation preserves the links. – Ted Corcovilos Jul 17 '17 at 22:26
  • This link helps: https://tex.stackexchange.com/questions/18687/how-to-generate-pdf-without-any-type3-fonts – Ted Corcovilos Jul 17 '17 at 22:28
  • That would explain why I had no problems since I declared fonts explicitly. – Alan Munn Jul 17 '17 at 22:31
  • @AlanMunn But it shouldn't be using type3 fonts if fontspec is loaded as fontspec declares fonts itself. – cfr Jul 18 '17 at 02:57
  • @cfr The problem wasn't specifically Type 3 fonts, but any type other than Type 1 or TTF. I tried to clarify below. – Ted Corcovilos Jul 18 '17 at 02:58
  • @TedCorcovilos Ah. OK. Yes. It will use opentype by default. (And Latin Modern rather than Computer Modern.) – cfr Jul 18 '17 at 02:59
  • @AlanMunn Well, if it won't accept opentype fonts, it makes sense. This seems extremely odd, even by the standards of submissions generally, which certainly set high oddity standards. – cfr Jul 18 '17 at 03:01
  • 1
    Also, the PDF versions need to be <=1.4. I don't understand the various PDF versions, but the fonts are stored differently in 1.5 and up. I'll amend my answer below. – Ted Corcovilos Jul 18 '17 at 03:01
  • @cfr Yes, I would be surprised if that were the case. But Fastlane is an old system, so one never knows. But in the last grant that I worked on we used fontspec and the Mac Times font, so I don't know for sure. – Alan Munn Jul 18 '17 at 03:07
  • Disregard my last comment. See new edit to OP. – Ted Corcovilos Jul 18 '17 at 03:10
  • The font issue may be unrelated to the hyperlink issue. After fixing the fonts, explicit URLs (those displaying http) work, but as @UlrikeFischer mentions above, that could be the PDF reader inferring a link from the text. Doing something like \href{http://tex.stackexchange.com}{Link} still doesn't work. I'm editing the example to test that case also. – Ted Corcovilos Jul 18 '17 at 04:51
  • You are asking us about some online service that does stuff to PDFs. Ask the purveyors of that service, not us. – Martin Schröder Jul 18 '17 at 08:16
  • I didn't mean that the fonts in themselves are the problem. But they probably influence the way the pdf are handled: Fastlane probably checks the pdf at upload. If it is as they want it they leave it alone (and the links intact), if not they correct it and in this process destroy the links/annotations like e.g. using \includepdf would destroy them. – Ulrike Fischer Jul 18 '17 at 08:41
  • If it redistills the PDF regardless, I don't think there is much you can do: it will destroy the links. Did links work for you, @AlanMunn? – cfr Jul 18 '17 at 14:06
  • @cfr I checked back and we didn't include any links it turns out. – Alan Munn Jul 18 '17 at 14:31
  • BTW, PDFs generated from MS-Word, for example, do not have their links broken when re-distilled. There is some bad interaction between LaTeX and the distiller. – Ted Corcovilos Jul 18 '17 at 16:25
  • @TedCorcovilos It isn't re-distilling them, though. The equivalent would be to export the Word document as PDF and then upload it and see if the links survived. I'm assuming you're talking about uploading the original Word document, so it is being turned into PDF for the first time. – cfr Jul 18 '17 at 18:01
  • @cfr Yes, if I convert a Word document to PDF (using built-in Print to PDF) then upload, the links are preserved. – Ted Corcovilos Jul 18 '17 at 20:06

1 Answers1

5

The problem is that Fastlane's PDF distiller can't process all fonts. See page 1346 of the Fastlane docs: https://www.research.gov/common/attachment/Desktop/FastLane_Help.pdf (Warning: the file is 30MB large.)

The instructions explicitly say to use only Type 1 or TrueType fonts. In particular, hyperref uses the mono font family for typesetting URLs, so this must be explicitly set.

That is the technical issue. But also, per the most recent NSF guidelines (https://www.nsf.gov/pubs/policydocs/pappg17_1/pappg_2.jsp#IIB2), the only allowed fonts are

Arial, Courier New, or Palatino Linotype at a font size of 10 points or larger;

Times New Roman at a font size of 11 points or larger; or

Computer Modern family of fonts at a font size of 11 points or larger.

Of these choices, I believe the only monospaced fonts are Courier New or Computer Modern Typewriter (if you have the .ttf version), so it is necessary to use something like

\setmonofont{Courier New}

to override the default (e.g. lm-mono) or otherwise disable all monospaced fonts in the document.