# inputenc error on special character in bib file

references.bib:

@Book{ref,
author = {{\u c}},
title = {Title}
}


main.tex:

\documentclass{article}

\usepackage[backend=biber, style=alphabetic]{biblatex}
\usepackage[utf8]{inputenc}

\bibliography{references}
\begin{document}

\cite{ref}

\printbibliography
\end{document}


This results in (using ShareLaTeX, if it matters)

! Package inputenc Error: Unicode char ̆ (U+306)
(inputenc)                not set up for use with LaTeX.


It seems to have something to do with how I've got biblatex configured, because it works with natbib. I would like to be able to use the \u{c} or {\u c} syntax instead of inserting the UTF8 character directly.

Update: @moewe pointed out that I probably meant {\v c}, which makes Biblaex happy. I think this question is still good though: what should I do if I did need {\u c}? Why does natbib happily print {\u c}, while biblatex throws an error?

• Just curious: Which language uses \u{c}/c̆? I know \v{c}/č, but I've never seen a c with breve. Wikipedia was not too helpful there. – moewe Mar 21 '19 at 18:28
• Looks like Slovenian: learnyouahaskell.com/faq – crockeea Mar 21 '19 at 18:31
• Lipovača is with C-hachek: \v{c}/č not \u{c}/c̆ – moewe Mar 21 '19 at 18:33
• @moewe I can't find where I copied that bib from anymore. Anyway, using \v{c} actually solves the problem I'm having (in addition to probably being correct). BibTex is happy to print {\v c}, but refuses {\u c}, even though natbib is happy to print {\u c}. – crockeea Mar 21 '19 at 18:41
• – moewe Apr 25 '19 at 6:45

Biber converts all ASCII-macros into their respective Unicode code points in order to be able to sort strings properly. In this case \u c gets converted to c̆ (U+0063 LATIN SMALL LETTER C+U+0306 COMBINING BREVE) because it has no combined character representation. Note that this conversion happens independent of the input. It does not matter if you write \u{c} or c̆ in the .bib file. Biber will always have the combination c̆ internally.

With \usepackage[utf8]{inputenc} Biber will output UTF-8 to the .bbl file, so that file will contain c̆. pdfLaTeX (with inputenc or without it) can not deal with combining accents (one of the issue is that the accent comes after the character it attaches to...) and so you get this error.

There are several ways to solve this. One is to tell Biber to output macros instead of UTF-8 characters. This is done by calling Biber with the command line option --output-safechars. An alternative is to tell Biber to output pure ASCII from within the .tex document. This is done by adding texencoding=ascii to the biblatex loading options.

For full Unicode support you should consider using a Unicode engine (XeLaTeX or LuaLaTeX). pdfLaTeX will always only support the parts of Unicode it can easily deal with, combining accents don't fall into that category (cf. Is there a way to get pdflatex to accept Unicode combining accents?).

\documentclass{article}

\usepackage[backend=biber, style=alphabetic, texencoding=ascii]{biblatex}
\usepackage[utf8]{inputenc}

\usepackage{filecontents}
\begin{filecontents}{\jobname.bib}
@book{ref,
author = {{\u{c}}, breve},
title = {Title}
}
\end{filecontents}

\begin{document}
\cite{ref}

\printbibliography
\end{document}


The issue does not occur with natbib or generally with BibTeX because BibTeX makes no attempt to convert {\u c} into its Unicode counterpart for sorting (it will just sort the character as c). The character is passed on unchanged as {\u c} to LaTeX.

As it turned out in the comments you actually want a c with caron/hachek (\v{c}/č) instead of c with breve (\u{c}/c̆). Because č has a precomposed Unicode character that LaTeX is set up to deal with properly, \v{c} will just work. I still find it nicer to input it as č and not \v{c}, but as mentioned above the input is not actually relevant because Biber performs a normalisation of the input anyway.

• Related tex.stackexchange.com/q/251261/35864 (because dotless-i + accent does not get converted to a pre-composed character, but remains a pair with combining accent instead). – moewe Mar 21 '19 at 18:49