4

In this thread, @DavidCarlisle asked for an example showing that \jobname doesn't handle underscores properly. Here's an example

\documentclass[11pt]{article}
\begin{document}
\begin{center}
\jobname \\
\today
\end{center}
\end{document}

If you call this file This_is_an_example.tex you'll see that the underscores are replaced by raised dots. Could you provide a fix for this? In the same thread people talked about fixes but it would be wonderful if somebody could provide an MWE that actually fixes the problem.

Leo Simon
  • 2,199
  • 2
    Doesn't \usepackage[T1]{fontenc} in the preamble fix the issue? – Troy Sep 10 '18 at 00:46
  • @Troy That is a good solution. Why don't you offer that as your answer. – A.Ellett Sep 10 '18 at 01:02
  • But the best solution (IMHO, of course) and not only in TeX is not use underscores or spaces in filenames. WikiWords are more readables and otherwise hyphens always work, even in the oldest MSDOS. – Fran Sep 10 '18 at 02:47
  • Related/duplicate: https://tex.stackexchange.com/q/351863/4427 – egreg Sep 10 '18 at 08:42

1 Answers1

8

If you're using pdflatex, you should pass \usepackage[T1]{fontenc} in the preamble, because the underscore _ character doesn't exist in the default OT1 (old text) encoding.

Doing so yields the expected result:

enter image description here

Troy
  • 13,741
  • Thanks very much! I'm puzzled about the underscore thing: _ is handled literally by the \jobname call, but if you put code_folding in the body of the text it throws the expected error. That seems inconsistent. – Leo Simon Sep 10 '18 at 04:59
  • 3
    @LeoSimon This "inconsistency" is because how TeX handles catcodes here. A call of \jobname returns all characters of the file name with fixed catcode 12 "other character" (or 10 for spaces). TeX normally handles these characters by just adding them to the output, which gives wrong results if the corresponding glyph in the font table is different from the glyph you expect at that position. OTOH, if a literal _ occurs in the text, the catcode hasn't been assigned yet and thus is given the default one (in this case 8 "subscript") as soon as TeX "sees" the character in the input stream. – siracusa Sep 10 '18 at 06:31