4

In the MWE below, I show that I have a bibliographic entry, which has had comment characters % embedded in the abstract field; while this passes with bibtex, with biblatex/biber it makes a problem, since biber will compact all lines of the field into a single line in the .bbl file. So I use a biber.conf file to completely avoid having the abstract field entered in the .bbl file:

\documentclass{article}
\usepackage[
  bibencoding=utf8,
  backend=biber,
  natbib,
  style=ieee,
  isbn=true,
  url=true,
  defernumbers=true,
  sorting=nyt,
]{biblatex}
\usepackage{filecontents}
\usepackage{trace}
\usepackage{hyperref}

\begin{filecontents*}{\jobname.bib}
@article {jo-audm08,
  author = {Some Author},
  title = {{Testing the title of a paper}},
  url = {http://example.com/paper.pdf},
  journal={Proceedings of Some Conference},
  pages={123--127},
  publisher = {example.com},
  year={2008},
  mycustomfield = {whatever},
  lastaccessed = {Last Accessed: 13 April, 2009},
  lastmodified = {Last Modified: 10/28/2008 14:46:42},
  abstract = {%
In this paper, we would like to describe the employment of  .. %
  },
}
\end{filecontents*}

% http://tex.stackexchange.com/questions/32930/is-it-possible-to-suppress-a-specific-field-from-bibtex-bbl-in-biblatex/33309#33309
\begin{filecontents*}{biber.conf}
<config>
  <sourcemap>
    <maps datatype="bibtex" map_overwrite="1">
      <map>
        <map_step map_field_set="ABSTRACT" map_null="1"/>
      </map>
    </maps>
  </sourcemap>
</config>
\end{filecontents*}

\addbibresource{\jobname.bib}

\newif\ifDoingSourcemap
\DoingSourcemapfalse
% \DoingSourcemaptrue % uncomment this

\ifDoingSourcemap
  \DeclareSourcemap{
      \maps[datatype=bibtex]{
        \map{
          \step[fieldsource=mycustomfield]
          \step[fieldset=usera,origfieldval]
      }
    }
  }
  \DeclareFieldFormat{usera}{#1} % not mycustomfield
\fi

\begin{document}

Citing here: \cite{jo-audm08}

\printbibliography[sorting=none]

\end{document}

This MWE compiles fine with pdflatex test.tex && biber test && pdflatex test.tex && pdflatex test.tex.

Now, I want to use a custom field mycustomfield in my bibliographic entry, and for its handling, I've set up a \DeclareSourcemap which maps mycustomfield to usera of biblatex. So, I uncomment the \DoingSourcemaptrue line, and recompile; but the pdflatex call after the biber call then fails with:

Runaway argument?
{\field {journaltitle}{Proceedings of Some Conference} \field {title}\ETC.
! File ended while scanning use of \field.
<inserted text> 
                \par 
l.65 \begin{document}

... and one can afterwards confirm that:

$ grep abstract test.bbl
      \field{abstract}{% In this paper, we would like to describe the employment of .. %}
      \field{abstract}{% In this paper, we would like to describe the employment of .. %}

... with the enabling of the \DeclareSourcemap, the biber.conf is possibly ignored, and the abstract field ends up in the .bbl anyway, causing trouble.

So, how can I both use a \DeclareSourcemap in my tex file, along with the mapping already set in biber.conf (in this case, both have the abstract field ignored and unentered in the .bbl file - and use the mycustomfield as usera)?

  • That is an interesting problem. It is known that \DeclareSourcemap can only be used once (see also \DeclareSourcemap in biblatex). But I would have thought that Biber's biber.conf would still apply regardless. What I find odd is that Biber's documentations states that biber.conf takes precedence over .bcf while you seem to have experienced the opposite. – moewe May 30 '15 at 6:33
  • @moewe: While that's true of options and settings more generally, the precedence order is a bit different for sourcemap entries (see 3.1.2 of the Biber documentation or 4.5.2 of the BibLaTeX documentation) where \DeclareSourcemap takes precedence over the configuration file. Nevertheless, I would've thought that non-conflicting rules wouldn't, you know, conflict... – ig0774 May 30 '15 at 6:57
  • @ig0774 Ahhh that explains it, then. As I said two sourcemaps in a document are not possible (I seem to remember reading why some time ago, can't din it now, though), maybe that carries over to the .conf file as well. – moewe May 30 '15 at 7:29
2

While I'd still appreciate a more erudite answer on the interference demonstrated in the OP (between biber.conf and \DeclareSourcemap) in general, I think I managed to fix this particular case.

After stumbling at biber/biblatex: \DeclareSourcemap conflicting with bcf file?, and realizing that biber.conf actually looks like what is written in \DeclareSourcemap - I wrote this, instead, in the OP MWE:

\ifDoingSourcemap
  \DeclareSourcemap{
      \maps[datatype=bibtex]{
        \map{
          \step[fieldsource=mycustomfield]
          \step[fieldset=usera,origfieldval]
      }
        \map[overwrite]{
          \step[fieldsource=abstract]
          \step[fieldset=abstract,null]
      }
    }
  }
  \DeclareFieldFormat{usera}{#1} % not mycustomfield
\fi

... and this compiles fine, and basically does what the biber.conf used to do (eliminate the abstract field from the .bbl) - so the biber.conf seems not necessary any more (in this case at least).

  • Even though this doesn't really explain why the problem arose in the first place. It is definitely the way to go. I really recommend having all of Biber's sourcemapping manipulations in one place, so you don't forget about one and end up with something you didn't want. – moewe May 30 '15 at 6:34
  • This is correct - the problem is that the \DeclareSourcemap and the .conf file write are at the same "level" of maps and the most specific settings (the particular document) take precedence. I could potentially split this as I did with the "style" level of maps but as @moewe says, it will probably encourage real confusing with maps all over the place. – PLK May 31 '15 at 11:51
  • Actually, this may be a bug, looking into it. – PLK May 31 '15 at 12:02
1

This was a bug. Please try biber 2.2 dev version now on Sourceforge. biber 2.2 can be used with biblatex 3.0.

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.