Upgrade StorageChecking 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.
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.
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.
Does bibtex actually stumble over this or just the code highlighter?
'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.
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).
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.
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...
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.
BBT exports \vphantom'ed balancing escaped-braces as a workaround for this.