Sample file

@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}
}

BibDesk uses a less popular file syntax. Their support has instructions on converting from the syntax that Zotero uses:
http://sourceforge.net/p/bibdesk/mailman/message/27219484/

JabRef works for me and Zotero uses the same format for file attachments. The links are relative links, so the BibTeX file needs to be opened from the location Zotero saves it to. Which version of JabRef are you using? Does it list both file attachments in the file section of the general tab? Can you open any files from there?

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.

@karnesky
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 ?

I'll try JabRef on my Mac this evening. I am unable to replicate your bug report and it works as expected in both Linux and Windows for me. You might also try adding files in JabRef to see if your setup is working. JabRef's file links are documented here.

This app is able to import natively Bib file if they are correctly parsed

By "BookEnds is not BibTeX-native", I mean that it uses a different backend database. Zotero is not BibTeX-native either. While either program can import or export BibTeX files, this process is necessarily "lossy". This is because the schema of the backend database of Zotero and BookEnds is different than what is supported in BibTeX.

There should be a standard way of (BibTeX language) to write every entry field.

Unfortunately not. BibTeX is described by its author in BibTeXing. That is the limit of what is really "standard". You'll notice no mention of attachments/files/urls/pdfs/etc. in that document. BibTeX is a flat-formatted database, which is not maintained by a standards body. As such, it has not grown as smoothly as some of the XML-based formats that you mention.

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.

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 ?

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.

It means the third party who wrote the extension believes so. I use the exporter that ships with Zotero, as it works for me. The features of Better BibTeX are listed at https://github.com/ZotPlus/zotero-better-bibtex and you can decide whether those are useful improvements or not.

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.

Correct!. Pity that I cannot manage on emacs. I will try to check with RefTeX if something will work..Thanks for all support!

Hi @karnesky, thanks for checking the plugin out. To answer your questions:

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.

Hi,

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.

@Mykhailo: my scheme is a little rusty; does that simply replace the three-field `file` entry by just the path? That would be easy to implement into the translator itself.

It's in 0.7.30, but off by default.