inputenc: Unicode character ... not set up for use with LaTeX

Question

Note: This question turns out to be based on a mistaken premise, and the ‘aha!’ that may come from it, if you think you may have a similar problem, is that the pdftex in TeXLive 2018 handles UTF-8/Unicode characters differently (and better!) from the one in TeXLive 2017. I'm leaving it up, rather than deleting it, in case someone else enters a similar blind alley to me.

---

My system's configuration of inputenc appears to be missing some fallback setup, so that Unicode characters produce an error:

\documentclass{article}
\begin{document}
The remarkable double pulsar PSR J0737−3039A/B provides similar
higher-precision tests.
\end{document}

The character in the middle of the name, there, is a dash, U+2212. On one system, this works fine:

This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./try.tex
LaTeX2e <2017-04-15>
Babel <3.10> and hyphenation patterns for 84 language(s) loaded.
(/usr/local/texlive/2017/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2017/texmf-dist/tex/latex/base/size10.clo)) (./try.aux)
[1{/usr/local/texlive/2017/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
(./try.aux) )
(see the transcript file for additional information)</usr/local/texlive/2017/te
xmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb>
Output written on try.pdf (1 page, 16951 bytes).
Transcript written on try.log.

On another, not so much:

This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./try.tex
LaTeX2e <2018-12-01>
(/usr/local/texlive/2018/texmf-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(/usr/local/texlive/2018/texmf-dist/tex/latex/base/size10.clo)) (./try.aux)

! Package inputenc Error: Unicode character − (U+2212)
(inputenc)                not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.4 The remarkable double pulsar PSR J0737−
                                             3039A/B provides similar
? 

The first machine has (as you can see) TeXLive 2017, and has been used/tweaked/extended in normal use for a while (that is, it may be in a significantly but not drastically non-default state); the second is a freshly-downloaded TeXLive 2018 (both are macOS, but I'd be surprised if that's relevant).

I'm having difficulty seeing why this works on the first machine and not the second, and, separately, how to fix it.

The various related tex.stackexchange.com questions and answers (1, 2, 3, 4, 5) are generally concerned with specific characters, and the fixes suggested are to do with explicitly declaring characters, or using one or other alternative. I'm concerned with how it is that TeXLive 2017, or I (accidentally or deliberately), have apparently configured inputenc so that pdftex+inputenc works with this MWE, in a way that vanilla TeXLive 2018 doesn't.

A RedHat support question mentions updating the various map files that pdftex consults. This is clearly close to the answer, because I do notice that the first, working, system reads pdftex.map, and the second doesn't. My updmap.cfg looks broadly plausible, and kpsewhich pdftex.map produces /usr/local/texlive/2018/texmf-var/fonts/map/pdftex/updmap/pdftex.map with plausible contents. I've run updmap-sys; I haven't run the commands suggested in that RedHat thread, partly because I don't know what they do, partly because they seem specific to a particular font map, and partly because I'd like to make this a useful site question.

Things that I'm ruling out on immediate practical grounds:

• I don't want to fiddle with the inputenc declarations: the source, that the above MWE is an extract of, is using a publisher's style file, which I don't want to monkey with. For what it's worth, I can't spot any Unicode cleverness in the style files,
• Normally, the answer to any unicode question is ‘use XeTeX or LuaTeX’; since I'm using a publisher's workflow, that's not really open to me
• I could of course change the Unicode hyphen to just --, and this is what I'll probably do in fact, to make this problem go away.

Thus my question is: what do I do (or what have I done in the past) to make this MWE work unchanged with pdflatex?

I'm aware this is a slightly naïve question, and I haven't done a huge amount of digging into fixing it myself, but (a) to some extent I treasure my ignorance of pdftex+inputenc (just use XeTeX!), and (b) I'm surprised that I can't find a question matching this on TeX.SE, and it might be useful for this to be that question. I'd be surprised if I'm the only person to have this problem, but googling is surprisingly little help, partly since most folk ask, and have answered, a more specific ‘why doesn't character X work?’ question.

Answer 1

You did not get an error in earlier latex as the character would be dropped but with no error in the terminal just a missing character line in the log.

In current releases UTF-8 is assumed and you would have had no error had the input used an en-dash U+2013 but it is using U+2212 which is a minus sign. We do not, by default, pre-declare math characters for inputenc (and most math characters would generate errors if used in text mode, if they were declared).

So you could change the input to

The remarkable double pulsar PSR J0737–3039A/B provides similar

or if you really want to (mis-)use a minus sign here, add

\DeclareUnicodeCharacter{2212}{\textendash}