Checking for curly braces parity when exporting BIB-file [bug-report]

I stumbled across a very unpleasant issue when one exports an entry where only one of the curly braces in any of the field is present using either BibTex of BibLaTeX translators. Usually it is title, which is when auto-generated with Zotero (60 characters limit) can contained unpaired {.

As a result, file = {...} line in exported BIB-file cannot be parsed, as well as the following entries, which brings up numerous errors during a compilation.

I think one needs to implement a check for {} completeness in all exported fields when it comes to BIB-files, or improve algorithm for title shortening which wouldn't thoughtlessly chop the words and formulas, leaving conflicting leftovers such as this.
  • Could you give an example? I don't think I follow.
  • edited September 3, 2017
    @adamsmith Consider a paper by Foo Bar with a title 'Lorem ipsum dolor sit amet, consectetur {FeMx(CO6)}' (the latter is some kind of random chemical formula).

    Zotero renames attached PDF to 'Foo - Lorem ipsum dolor sit amet, consectetur {FeMsub.pdf' due to 60 character limit. When I export this item with BibLaTeX translator, I get the following BIB-file:


    @article{foo_lorem_????,
    title = {Lorem ipsum dolor sit amet, consectetur \{{FeM}$_{\textrm{x}}$({CO}6)\}},
    author = {Foo, Bar},
    file = {Foo - Lorem ipsum dolor sit amet, consectetur \{FeMsub.pdf:D\:\\Andselisk\\Documents\\Zotero\\storage\\LZ8D8TLI\\Foo - Lorem ipsum dolor sit amet, consectetur \{FeMsub.pdf:application/pdf}
    }


    If you open this code in an editor with a syntax highlighting, you will see that curly braces are improperly paired now, e.g. the last one serves as a closing } for 'file ={' field instead of '@article{' due to the way Zotero chops the file name.

    I guess in general when one deals with BIB-files, a check for {}-parity in entry fields is a must. Otherwise a lot of things can go wrong.
  • edited September 3, 2017
    Maybe I'm still missing something, but there's no reason why escaped curly brackets would need to be paired -- the fact they're escaped means they're no longer a special character.

    Does bibtex actually stumble over this or just the code highlighter?
  • edited September 3, 2017
    @adamsmith Yes, aside from looking weird in the text editor (syntax highligthing in both VSCode and TexStudio looks messed up after the problematic entry) biber returns

    'warning: possible runaway string started at line 688' (where the file field is)

    followed by

    'syntax error: at end of input, expected one of: number, name (entry type, key, field, or macro name) or quoted string ({...} or "...")'

    and fails to create bibliography. Manually removing the lone bracket \{ solves the problem entirely.
  • edited September 3, 2017
    I honestly don't get either why an escaped character causes this issue. Is there a way to tell Zotero just not to include certain fields (file path, for instance)?

    I personally don't need this info in my BIB-file and it now only causes this error. I can certainly clean up fields with JabRef and it works, but it's rather tedious to do so after every export when I add new entry(ies).
  • Commenting out this line: https://github.com/zotero/translators/blob/master/BibLaTeX.js#L770
    should be all you need to do.

    An actual fix is a lot more complicated, since the curly bracket is part of the actual filename in Zotero, so any fix for it would need to be for the whole filename routine in Zotero.
  • @adamsmith Many thanks, commenting out that line worked like a charm. No 'file' field, no error upon compilation.

    I hear the new Electron-based Zotero is being developed, so maybe one could resolve this issue in the upcoming releases on a new engine...
  • We could try to use \leftbrace for file names instead as it is suggested in https://tex.stackexchange.com/a/109066/73301 , i.e. something like

    if (attachmentString) {
    attachmentString.replace('{', '{\leftbrace}').replace('}', '{\rightbrace}');
    writeField("file", attachmentString.substr(1));
    }

    This should hopefully work for BibTeX and Biber then, but would need more testing for importing into JabRef and any other tool we want to have support.
  • @zuphilip Great find on Tex.SE, thank you! I manually replaced '\{' with '\leftbrace' and it also did the trick. It looks like BibLaTeX.js and BibTeX.js translators need to be aware of such case.
  • I believe stock BibTeX can handle either form. Is this a bug in biber or am i missing something? If it is a biber bug, I don't think we should change BibTeX.js until we get confirmation that modern versions of other popular tools such as JabRef are able to open the files linked using either form.
  • Yes, more testing would be needed. Did you test it with Biber?
  • I haven't tested with anything. I will next week (I am abroad now without access to my usual machine for these things).
  • The escaped-but-unbalanced braces triggering biber could be caused by this. The fix PLK talks about should be out and available (it was on the DEV branch in '15 after all), but not everyone can/does upgrade their LaTeX suites when a new one comes out.

    BBT exports \vphantom'ed balancing escaped-braces as a workaround for this.
  • BBT exports \vphantom'ed balancing escaped-braces as a workaround for this.
    Not sure if that's desired behavior for the file field, as it'd break linking by third party apps the same way other transcriptions might.
  • Oh sorry I missed that. I don't think bbt does it for the file field.
  • For the record, I use TexLive 2017 and biber 2.7 shipped with it.
  • Braces in the filenames are always going to be nasty TBH; the best you can hope for is that the exporter mangles them in a way that your references compile without error.
  • @andselisk BBT can skip fields in the export; BBT is mostly usable right now but I'm in the thick of getting it fully ready for Zotero 5; those who use BBT in this stage will have to upgrade very often (and currently that's manually). Closer to a release a day than a release a week as I work towards feature-completeness.
  • Yeah, I think we might just want to consider stripping braces from filenames. There's no reason to not do that. We'll have to talk to Joscha to do the same with zotfile
Sign In or Register to comment.