Bibtex export error due to improper handing of "{" in abstract

When an abstract contains the symbol "{", zotero exports it to Bibtex file in verbatim. However, if the symbol "{" is not properly matched, this will lead to a Bibtex parsing error. For example:

@article{a_test_1800,
title = {test article},
volume = {1},
abstract = {{asfdaf{afaf}},
number = {1},
journal = {Journal of a},
author = {B A},
year = {1800},
pages = {1}
}

will cause a bibtex error as the curly brackets in the abstract fields are NOT matched.

This could happen if there is unmatched "{" or "}" in other fields too. Escaping it with "\{" and "\}" may be a solution.
  • Good idea. I had this problem when some unmatched curly braces were in the abstract field of some items I downloaded. As anyone knows who has used Zotero for long, online databases can have ANYTHING in them, and unmatched stray braces are only the beginning! Could the BibTeX exporter check this?
  • Forgive me for bumping an old thread, but I'm having this issue too, which includes filenames with braces. For example, if you import the article from http://journals.aps.org/prb/abstract/10.1103/PhysRevB.91.081107, you get "Aoyama et al. - 2015 - Multiferroicity in orthorhombic $Rmathrm{Mn}{mat.pdf", which causes problems when it shows up in the bibtex file. I'm guessing that Zotero creates the filename from the first n characters in the title. It would make life easier for me if all curly braces and other bad characters were removed.
  • The braces are backslash escaped on export for me. Can you post the actual BibTeX output from Zotero on https://gist.github.com and link to it here?
  • Okay, I checked and it does backslash the braces, but nevertheless bibtex generates an error message. I don't know if this should be considered a zotero issue or a bibtex issue.

    Here's the relevant part of the .bib file I exported: https://gist.github.com/js54434/4dde579bbf29668f0a52 .

    Here's the error I got when running bibtex on the paper: https://gist.github.com/js54434/23cf98ce2a5bc07d2d24
  • Looks like a BibTeX bug to me, but I doubt that anyone will bother fixing it. We'll just have to strip the characters on export from the file field.

    It's a bit odd though, because I'm seeing the same issue with the abstract field, and I would have expected someone to already have reported this if it was a widespread problem (braces have been backslash escaped for a long long time). Maybe the BibTeX parser that ships with TeX Live is at fault here after all. It would be good for someone to check on a different setup (and also with Biber).

    I'll wait until I get a confirmation of this bug with another BibTeX compilation to release a fix.
  • Gah!! Same problem with Biber. As long as there's an unmatched backslash-escaped brace, it breaks the parsing. I feel like I'm just missing something, because it's pretty clear rule that you can escape braces with backslash.
  • Could someone set up with a LaTeX environment test if replacing { and } with {\textleftbrace} and {\textrightbrace}, respectively, works as expected for the above BibTeX data? Biber seems to be ok with it and I don't think BibTeX parser will mind it either. I'm just wondering if most LaTeX engines will be ok with this (I don't think this macro is used that often, since I had a pretty hard time finding it).

    For file field we'll strip it out anyway, because that will create fewer problems with compatibility.
  • Actually, nvm the above. It's {\textbraceleft} and {\textbraceright}. If someone can test it anyway that would be good, but I got some unfortunate answers on TeX stackexchange: http://tex.stackexchange.com/questions/230750/open-brace-in-bibtex-fields
  • OK, I think we have a solution thanks to zuphilip. Update your translators via Preferences -> General -> Update Now and try again.

    We're now stripping out braces from the file path and file title.

    For all other fields, we're using special escaping that doesn't break the BibTeX processor. See the TeX.SX link above for more details on that.
Sign In or Register to comment.