4

I'm trying to print a path to a file inside the bibliography. It should be readable, not clickable. Therefore it does not have to by correct in terms of url rules such as no spaces etc. However it does not display umlauts like ä correctly.

my MWE looks like that:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[backend=biber]{biblatex}
\usepackage{hyperref}
\usepackage{filecontents}
\begin{filecontents}{\jobname.bib}
 @misc{mean_well_rcp-1600_2018,
    langid     = {english},
    title      = {RCP-1600 ä},
    file        = {C:/Test ha Földer/file},
    shorttitle = {RCP-1600},
    date       = {2018-01-15},
    author     = {MEAN\textasciitilde{}WELL}
}
\end{filecontents}
\addbibresource{\jobname.bib}


\DeclareFieldFormat{file}{\mkbibacro{file:}\addcolon\space#1}
\renewbibmacro{finentry}{%
 \finentry\addspace
 \printfield{file}%
 }
\begin{document}
 \cite{mean_well_rcp-1600_2018}
 \printbibliography
\end{document}

the log file: test.log

  • I Tried it using, the note entry instead of the file entry. It works with the note entry. – Jannis.D Jul 29 '18 at 5:09
  • 1
    Fields like url and field are read verbose by biblatex, i.e. special characters do not have their usual special meaning, so you can use & and # in URLs without LaTeX complaining bitterly. Since non-ASCII chars are realised as active characters with inputenc they lose their meaning, too. You could switch to a Unicode engine (XeLaTeX or LuaLaTeX), or you can use a non-verbose field if you promise not to include special characters... – moewe Jul 29 '18 at 5:13
  • Ill switch to the note entry for now! Comes with the added benefit of being accessible inside of Zotero. Thanks. – Jannis.D Jul 29 '18 at 5:18
3

Fields like url, doi and field are verbatim fields. Verbatim fields may contain special characters like $, %, # without upsetting LaTeX. The contents of the field are sanitised (\detokenized) before printing and so the special characters just print as themselves and not with their usual special meaning.

With inputenc non-ASCII chars like ö, ä, ... are realised as active characters. But when they are \detokenized, they lose their active status and become plain UTF-8 characters again. LaTeX then fails to handle these characters as expected. You can verify that with

\detokenize{ö$}

in your document, it comes out as

Ãű$

and not as an ö and an error about a missing $.

There are some workarounds, but they are not particularly satisfying

  1. Use a Unicode engine like LuaLaTeX or XeLaTeX. Unicode engines treat non-ASCII characters as single, normal character and not a macro (active character), so these characters don't get mangled when passed through a verbatim field.
  2. Use a non-verbatim field (or change the type of field from verbatim to literal), that will allow non-ASCII chars like ä, ö and ß to work, but you can't use special characters like $, \, #, & any more without LaTeX complaining.
  3. Use a legacy encoding such as latin1. With these old encodings only 256 characters are available natively, but the supported non-ASCII chars will be handled as themselves and not as an active character (latin1/ISO 8859-1 supports ä, ö, ü, ß, é). Just like with LuaLaTeX and XeLaTeX they survive the detokenization.
1

Apply \scantokens:

\begin{filecontents}{\jobname.bib}
 @misc{mean_well_rcp-1600_2018,
    langid     = {english},
    title      = {RCP-1600 ä},
    file        = {C:/Test ha Földer/file},
    shorttitle = {RCP-1600},
    date       = {2018-01-15},
    author     = {MEAN\textasciitilde{}WELL}
}
\end{filecontents}

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[backend=biber]{biblatex}
\usepackage{hyperref}

\addbibresource{\jobname.bib}


\DeclareFieldFormat{file}{\mkbibacro{file:}\addcolon\space\scantokens{#1\relax}}
\renewbibmacro{finentry}{%
 \finentry\addspace
 \printfield{file}%
 }
\begin{document}
 \cite{mean_well_rcp-1600_2018}
 \printbibliography
\end{document}

enter image description here

  • This also doesn't support special characters ($, #, &) in their detokenized meaning, right? – moewe Jul 29 '18 at 12:13
  • 1
    @moewe I don't think so, unfortunately. But directory or file names containing them should be banned. – egreg Jul 29 '18 at 12:30
  • I can't say I disagree, though I tend to avoid non-ASCII chars as well. If I understand correctly, your solution should come done to turning a verbatim field into a literal field (in biblatex parlance) by way of its field format. – moewe Jul 29 '18 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.