Upgrade StorageProblem with export to bibtex
Hello,
As most of my work with text documents is with Emacs, AUCtex and Ebib So I need a bibtex version of my Zotero library . The export of just the library without the papers pdf is ok. Problems are when I try to export the pdf files associated. I tried the "bibtex" export. Exporting of the pdf files is without problem (one *.bib file and one 'file' folder containing the pdfs). The problem is when I try to open the pdf file on Ebib it says it cannot find the file associated. Same with BibDesk (in the attachment window there is no pdf associated). The problem seems with the modalities of Zotero to rename the attachment in a way which is not recognize by bibtex (this is my consideration of course). So I tried using the "Better BibTeX" export option but I get the error message:
An error occurred while trying to export the selected file. And just a
blank file as export. The same error message with the other option "Better BibLaTeX" and "BibLaTeX".
I saw in previous posts (https://forums.zotero.org/discussion/21877/bibtex-export-with-path-of-pdf-files/) that this kind of problem had to be fixed in v3. Any suggestions ?
Firefox 30. MacOS 10.9. Zotero 4.0.21.5
Report ID:1230160954
As most of my work with text documents is with Emacs, AUCtex and Ebib So I need a bibtex version of my Zotero library . The export of just the library without the papers pdf is ok. Problems are when I try to export the pdf files associated. I tried the "bibtex" export. Exporting of the pdf files is without problem (one *.bib file and one 'file' folder containing the pdfs). The problem is when I try to open the pdf file on Ebib it says it cannot find the file associated. Same with BibDesk (in the attachment window there is no pdf associated). The problem seems with the modalities of Zotero to rename the attachment in a way which is not recognize by bibtex (this is my consideration of course). So I tried using the "Better BibTeX" export option but I get the error message:
An error occurred while trying to export the selected file. And just a
blank file as export. The same error message with the other option "Better BibLaTeX" and "BibLaTeX".
I saw in previous posts (https://forums.zotero.org/discussion/21877/bibtex-export-with-path-of-pdf-files/) that this kind of problem had to be fixed in v3. Any suggestions ?
Firefox 30. MacOS 10.9. Zotero 4.0.21.5
Report ID:1230160954
@article{roxas_acute_2011,
title = {Acute Myocardial Infarction Caused by Coronary Embolism from Infective Endocarditis},
volume = {40},
issn = {07364679},
url = {http://linkinghub.elsevier.com/retrieve/pii/S0736467908004587},
doi = {10.1016/j.jemermed.2007.12.041},
language = {en},
number = {5},
urldate = {2014-06-14},
journal = {The Journal of Emergency Medicine},
author = {Roxas, Czarina J. and Weekes, Anthony J.},
month = may,
year = {2011},
pages = {509--514},
file = {Roxas e Weekes - 2011 - Acute Myocardial Infarction Caused by Coronary Emb.pdf:files/1261/Roxas e Weekes - 2011 - Acute Myocardial Infarction Caused by Coronary Emb.pdf:application/pdf}
}
http://sourceforge.net/p/bibdesk/mailman/message/27219484/
JabRef
http://imgur.com/k68eci1
This is after importing everything looks ok. But when try to open the pdf file associated we have an error message:
http://imgur.com/4K0j2yi
BibDesk
http://imgur.com/MNCca7c
Again importing of all references is ok except for the file association. As you can see in the next screenshot it recognize just the doi of the ref.
http://imgur.com/yoH6AOo
Bookends ,limited to 50 ref max, behave in the same way:
http://imgur.com/L3mLWip
And again emacs with Ebib
http://imgur.com/x3eSY0W
http://imgur.com/EtfXyrs
So the problem is still with the file field.
One more question why the the "Better BibTeX" export option is not working ?
http://imgur.com/GONsc7F
BibDesk uses a different format for file attachments. We don't expect it to work. If you add file attachments to a file in JabRef, the file will not work with BibDesk either.
BookEnds is not BibTeX-native. You may be able to import Zotero RIS. However, there are questions in their support forums about importing attachments from JabRef and BibDesk to BookEnds, so I suspect their BibTeX importer does not process attachments. If you are able to import <i>any</i> BibTeX file (including a BookEnds-produced file) with attachments, please show the syntax that it uses.
The error that you get in ebib shows that it does not use the same convention that JabRef, Zotero, and others use for the file field. It likely only takes the path to the file (with no description of the file or mimetype). Based on this, I don't think ebib would open attachments from JabRef or from BibDesk either.
In summary, you can see the problem is that there is not really a standard way to attach files. You list four programs. I believe one of those programs does not process attachments in BibTeX at all. The other three each use a different format, and none would be able to exchange attachments with another.
Zotero uses the same format as JabRef, which preserves the most information (and can likely be post-processed into the other two formats you identify) and is used in some other applications. That should work & I'd be interesting in finding why it doesn't work for you. Further, zotero is better at IMPORTING from more attachments schemes than the other programs. We try to follow Postel's robustness principle. While some of these programs work under the philosophy of preserving the BibTeX file you give them, it should be possible for the developers to improve how they handle attachments added in other programs.
https://github.com/ZotPlus/zotero-better-bibtex/issues
You are moving around problem without facing it.
-----
Which version of JabRef are you using?
2.1
----------
Does it list both file attachments in the file section of the general tab?
See my previous post (yes it shows the files (PDF and Web) but it does not open (unable to open link).
-------
BookEnds is not BibTeX-native.....
This app is able to import natively Bib file if they are correctly parsed. And oddly enough Zotero is one of the few which exports a bib file which is read easily by Bookends except the problem of the file entry attach. The same problem we have even with Endnote v.7 at University. Tomorrow I will send details. Anyway you can circumvent the problem pointing manually to the folder where are stored the file. But the attachment will be made after parsing the metadata of the pdf not of the bib entry. Clear ?
---------------
The error that you get in ebib shows that it does not use the same convention that JabRef...
Well here I am not so sure. There should be a standard way of (BibTeX language) to write every entry field. As a matter of fact if I export in XML language everything goes well with all programs which accept this.
But still there is another more important problem unsolved which nobody mention. Why there is one more option in Zotero called "Better BibTeX" and why it is not working ?
BibTeXing describes how BibTeX is "extendable" this way: "An entry can also contain other fields, which are ignored by those styles." Because of this, many people have created new fields in BibTeX to store more information (such as attachments). However, there are some inconsistencies in how different programs implement those fields. You can confirm this by exporting a BibTeX file from ANY of the software you mention & importing it into ANY other program you mention. Attachments will not work.That extension is not maintained by the Zotero developers. I don't use it and don't have experience with it. You'd be better off getting support from the developers of that extension, and adamsmith pointed you to them.
If there is a third party plugin called "Better" BibTeX export means there are problems in the original export plugin of Zotero. Right?
In my opinion, some of those features should eventually make it into the Zotero BibTeX translator (indeed: some already have). I'll run through each feature, so you can understand the slightly differing philosophies/motivation for having multiple ways to export BibTeX & so you can decide which is better for you.
Some of the unicode/html<->TeX entity conversions have already made it into Zotero's exporter. There may be others that still should come over; I haven't checked in a while.
The chief reason people use it seems to be to change their citation keys. The automatic generation of the keys is a limitation of zotero (I re-do mine using JabRef). However, I don't think the implementation in "Better BibTeX" is the right longterm solution. We need a separate field to store this and may eventually get one.
The ability to customize exports may be useful to some. However, it runs counter to the design of any of the translators zotero uses: we try to generate one export format as correctly and completely as possible, and do not expose unnecessarily complex customizations.
JabRef groups and "forthcoming" as a date are not "standard" BibTeX. They may be useful enough and not break things that Zotero should eventually include these; I'm neutral on those.
The pull export is a cool feature. But it isn't really part of the translator code per-say. And I have no clue how well it works with the rest of the Zotero code or if it can be more generally useful (for workflows that use citeproc-hs/pandoc, for example). Having an extension implement "experimental" features like this one seems to be great to me.
I see that the title of your file is 'untitled'. I believe this means you opened JabRef and either used the "Import into new database" function or created a new database, and used the "Import into current database" function and then did not save the database. Because of this, JabRef doesn't know how to resolve the relative filepaths. You would need to save the file in the same directory as the BibTeX file that Zotero created.
Alternatively, you can just use the "Open database" function in JabRef.
I don't use ebib, but you should be able to use a regex to get one attachment to work. This takes whatever the LAST attachment is:
sed 's/file = {.*:\(.*\):.*/file = {\1}/' <old.bib >new.bibIt will still be a relative link. If ebib doesn't work with relative links, you can add the rest of the path into the replace portion of the regex. You can also rewrite the regex to only work for pdf files if you like.Yes, I do think my translators are structurally better for BibTeX users. The translators, accompanying support code in the plugin and the build system have now moved on beyond things that can simply be incorporated in the stock BibTeX translator; that's not to say I think the stock translators ought to be replaced (they're sufficiently useful to many people), but there are some structural problems in the stock BibTeX support that are not likely to change (like shifting citation keys depending on which selection of references you export) that are live problems for me.
I'm totally with you that a separate field would be the best option for storing the cite key, but this is unfortunately not up to me. Like you I believe that storing the key in the extra field is not the right long-term solution, but I've explored many other options and found only annoyed responses in return ("just wait until the infrastructure allows for something better"). Once a new option becomes available that doesn't horribly break sync you can rest assured I'll be all over it, but that option doesn't seem to be around the corner, and so I make do with what works, rather than what theoretically ought to exist.
I fully agree that the configuration options for the translator are complex, but this is because BibTeX users quite often *want* this complexity (it's no accident that JabRef has many of these things, too). There is a single option in there that I regret implementing (the fancy urls), but I'm keeping it in in order not to break things for existing users; all the rest I personally actively use. And yes, JabRef groups and "forthcoming" dates are not "standard" BibTeX, but as you point out, there *is* no standard BibTeX, and biber at least *does* support it, and in the end, that's what counts, much more so than what any doc says.
As for the pull export... that started out as a "because I can" experiment; The pull export uses the existing plumbing of the embedded http server; if that stops working, then so does Zotero standalone and the Chrome plugin. It works well with the rest of the zotero code in the sense that it doesn't interfere with it, but I don't think it's a feature that has much use outside the user base for the plugin, and in fact I think that once I have the auto-export feature going, it's popularity (if any) is going to wane fast, as most BibTeX users seem to prefer physical files. It was useful to me because I tended to forget to export before compilation, but the auto-export is going to take care of that.
I would not consider the plugin experimental anymore at this point though. It breaks more often than the stock translator, but then it also gets new features much more often, and I have accumulated a substantial and growing set of automated tests; any bug report issued gets a new test added to the suite. I use it for day to day work, and I take disruptions users of the plugin experience very seriously; I try to keep to same-day fixes.
That all said, it's not for everyone; its out-of-the-box configuration works well enough, but tweaking the settings does have a learning curve, the docs are written by me (which means they're imperfect) and it requires a github account just to get support; I can well understand people having better things to do with their time.
In case it wasn't clear from this five month old post, I didn't have any real questions. It seemed that Enrico68 did not understand the differences between your extension and the stock BibTeX translator and assumed (incorrectly, I think) there must be problems in the stock translator due to the name of your extension.
But I do appreciate the effort you took to describe the differences further and more clearly.
I only visit these forums occasionally; in this case, my github stats led me here :) Right you are, on re-reading, yours weren't really questions; let's go with "feedback on comments" and split the difference.
I did not intend the name of my plugin to suggest the stock BibTeX translators are broken; as a matter of fact I try to have the default config track the behavior of the stock exporter, which I think has made very sensible choices in the translation to BibTeX and the impedance mismatch it has to solve in doing so. I do stand by "Better", though; the fact the JabRef is needed for many people (not just you) to make Zotero a dependable part of a LaTeX workflow can be thought to indicate that there is room for improvement. Perhaps "Improved BibTeX" or "Extended BibTeX" or "BibTeX Deluxe" or some other even more pretentious title would have been better, but I think we're stuck with the existing name. Unless the Zotero team really thinks this leads to more of the question that drew me here, and sees it as a slight against them. I certainly am not out to annoy the Zotero devs (Hi! Love you!), so if that were the case, I'd be open to rename. But I'd rather not.
Oh and you're totally right that not everything relates directly to BibTeX anymore. Several features that could in fact have broader application have made their appearance over time (ye ole feature creep) such as for example the auto-export I'm working on now. I do try to either split off unrelated features or defer to existing plugins, but to go with the the auto-export example, this solves some performance problems I've had with existing auto-exporters in a way that intricately relies on behavior in the bundled translators. Not impossible to generalize if it were desired, but it would require changes to every existing translator; not something I think should be undertaken lightly. So in that sense, yeah, the plugin as a test-bed is really much more spot on than I initially considered.
Looks like we're in agreement. How did that happen? Let's not get word around that I might be agreeable.
--- (let* ((file (nth (1- n) files))+++ (let* ((file-jr (nth (1- n) files))+++ (match (string-match "\\(:\\)\\(.\\)*\\(:\\)" file-jr))
+++ (file (substring (match-string 0 file-jr) 1 -1))
`
Actually, that's solely a ebib problem, because such file-field format is a years-endured jabref standard.