# inputenc: Unicode character … not set up for use with LaTeX

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.

• The default encoding in 2018 is utf8, not so in 2017. In 2017, when there is no input enc specified ascii (?) seems to be assumes, so everything else is ignored, including your U+2212 and my Danish vowels æøå. – daleif Mar 29 '19 at 11:58
• To emphasise daleif's point: In the 2017 version the dash would not have been printed (and there would have been no error): That is arguably worse than the new behaviour. You can get back the old behaviour (not that I would recommend it) by adding \RequirePackage[2017/04/15]{latexrelease} to the beginning of the file to roll back all of the LaTeX kernel changes or \UseRawInputEncoding to opt out of only the UTF-8 change. Info on the April 2018 change can be found in latex-project.org/news/latex2e-news/ltnews28.pdf – moewe Mar 29 '19 at 12:19
• Grrrr – that's it! I was sure I'd checked that, but in trying to compare try.pdf from three different installations, I must have confused myself. The 2017 version does indeed omit the character. Oh well: the useful thing to come out of this, from the TeX.SE point of view, is that for 'unicode and pdftex' questions, the distribution date now matters. Also: are you saying that the default encoding for pdftex is now UTF-8? – I hadn't been aware of that: that presumably makes quite a few problems go away. If (either of) you could make a few-line answer of this, I'll happily accept it. – Norman Gray Mar 29 '19 at 12:21
• The default encoding for all LaTeX documents is UTF-8 now, yes. (Even for pdflatex.) – moewe Mar 29 '19 at 12:21

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}

• Thanks, David (and daleif and moewe). I should note that it wasn't me abusing a minus sign there (I'd hate you to think I'd deliberately do anything so monstrous!): I think, looking through past commit logs, that I must have cut-and-pasted the pulsar name from another source. That I thought the file had been 8-bit clean – because that matters (^W used to matter) to pdftex – added to my confusion. – Norman Gray Mar 29 '19 at 19:18
• @NormanGray it's OK, I'll blame you anyway:-) – David Carlisle Mar 29 '19 at 19:19
• On reflection (and in a slightly deranged pursuit of precision, and after swapping out my TeX head and swapping in my astronomical one), the original version with the minus sign is probably correct, and a version with a dash of any type incorrect (and therefore – of course – vicious, monstrous and to be noisily execrated). The numbers here, though they combine to form a name, are based on coordinates, so the character between them is indeed either a plus or a minus sign. The spacing around it is of course a separate issue, which this comment box does not give me space to discuss with the de... – Norman Gray Nov 27 '20 at 12:18