Papers Support Forum

Hi Amir, thanks for the follow up. However we started the statement with the fact that we notice that many people see Papers as a bibdesk replacement. This is not our intention, and we will certainly think about better integration in the future if more people ask for this..

Bertil wrote:

the semi-colon do not work in LaTeX, and I have to switch them from within BibDesk

Can you detail exactly where this is a problem? When do we have to make sure no semi-colons appear, you mean like in titles or abstracts?

Mek,

With all due respect, I think you're missing an opportunity here. Papers and BibDesk do different things, that's true. But the people who are comparing the two have an ideal application in mind, which (at this point) neither Papers nor BibDesk is. That application would handle:

1) Finding references of all sorts (journal articles, books, etc) through online repositories and library catalogs
2) Organizing PDFs and other downloaded references on the user's computer
3) Reading the PDFs/other materials, hopefully with a nice full-screen interface and rudimentary notetaking ability
4) Citation management and integration with Microsoft Word/Pages/Mellel/Nisus/LaTeX

Papers is good at #1 and #2, as long as we deal with pdf/journal article only, and it's ok at #3, but does none of #4. Bibdesk kinda does #1, doesn't do much of #2, farms out #3 to Skim, and with #4, only does LaTeX well (there's an AppleScript that handles Pages). Other applications (Endnote, Bookends) handle some of this package, but not all. An application that could do all of these things would find a big audience, I think--I would much rather do all of this in one application than switch between 2, 3, or 4 programs, and the problems of transferring/syncing databases between them. A program that does everything I list above would appeal to academics and researchers across many fields.

Hi, I just downloaded Papers today and I'm starting to work with it.  I also would like better integration with Bibdesk--specifically the ability to define what I would like to cite key to be.  I am a biochemist and I already have a library of over 200 PDF articles on my computer.  I have come up with my own naming system, which I cannot integrate with papers (Author's last name year_journal abbreviation).  My specific case may be difficult to accommodate because I use 3-4 letter codes for journals that I came up with myself, however, being able to change the cite key at all would be great.  There's no way I'll ever remember the ones that Paper automatically assigns, but I might be able to work with something I defined.  As it is, I will probably continue to manually enter info into BibDesk myself.

As a biochemist, I do use LaTeX whenever I can.  I got introduced to it when writing a senior thesis which had a lot of math in it.  I do have to use Word at times because other people aren't familiar with LaTeX, but I think more and more people will come to use it.

Along those lines, I save my PDF files with the same name as their cite key.  I would like more control over how the files are stored.  Using the full journal name, or even the standard abbreviations in many cases, is very cumbersome, so a more compact style would be nice.  Allowing users to define their own list of abbreviations would be very nice, and user-generated lists could even be shared between members.

Julia

Gee, guys, watch your tone and read the original postings, would you? :-)

Mek pointed out very clear that the mentioned programs are intended for different "audiences" and were optimized for their purpose. Endnote has its main focus on Word users and works well (so far...) while BibDesk is optimized for BibTeX/LaTeX users and offers many tools for that and works great. Papers on the other hand focuses on PDF handling, searching the library and  organizing it - and it does that in a way unprecedented by any other program in that field (I won't even get started on Endnote!!!).

He also admitted right away that they have noticed Papers' popularity among TeXers and are eager to improve the integration on that area. In various other posts regarding BibTeX (e.g. regarding the cite keys) they always wrote that it's on the to-do list for future versions. And they did already prove in the past that they are happy to add features requested by users. So how about cutting them some slack? To-do lists for software (as well as in science in general) are pathologically long and there are at least as many non-TeX users who moan for features they think are most important (don't get me wrong, I'm a passinate TeXnician...! :-).

Due to the simplicity of a BibTeX database (being just a simple text file) and the many TeXers using Papers it should be fairly sure to assume that they will improve the BibTeX integration, but things like that need time. If there are particular problems, just post them as separate threads and they surely will be solved by a fellow BibTeXer!

mek wrote:

Let me add that we are definitely committed to improve BibTeX support (which doesn't necessarily equal replacing Bibdesk)

Good news!
I guess what we really need most urgently (and as a first step) is the export of a *correct* and useable .bib file.

mek wrote:

and that the next major release of Papers won't disappoint you in this respect.

Nice! When can we expect the release?
Will its price-tag be comparable to current 1.x version? Will there be a discounted upgrade for 1.x users?

Hi Mek,

I would also love it if Papers could be better integrated with BibDesk but there are workarounds. My only major issue related to the .bib files exported by Papers is:

Papers seems to have a problem exporting characters like alpha, beta etc. For example it replaces sigma with '<CF><83>'  which BibDesk hates! Benjamin Bulheller, on another Papers thread, posted a script which can be run on the *.bib file output by Papers. The script is available on the authors webpage:

http://www.bulheller.com/scripts/index. … erlScripts

The script fixes all the weird characters. It can also create a shorter .bib file with only the fields you choose. If Papers could just output the right file to start with that would be excellent.  Still I don't mind the one extra step.

Thanks for a great app!

:)

P.S or possibly Tips:  There are workarounds for customising cite keys. You can do that in BibDesk. One very cool reason to have BibDesk is autocompletion with TeXShop. As long as you have your .bib file open in BibDesk** you can autocomplete reference in TeXShop. Just type \cite{A and press apple-esc 
All the authors whose names start with an A appear in a drop down menu from which you can select the appropriate reference. The correct citeKey is  then inserted into your TeX file.  I no longer have to remember CiteKeys. Yay!

** BibDesk must have TeXShop included in Preferences->Completion 
and
TeXShop must have Auto Complete selected in Preferences.

Last edited by pnair (2008-06-27 15:13:42)

Gday - I wanted to contribute my two cents on Papers (and yes, I read the previous posts, Kinlee). I thought Chris (post #7) did an excellent job of highlighting strengths and weaknesses of BibDesk vs. Papers right now. The number one priority (and the only thing keeping me from switching to Papers) is the inability to generate a custom cite key from the metadata. I'm a physicist and LaTeX user who loves the browsability and easy import of Papers, but I need be able to generate a key so I can type in papers easily. Make it happen and I switch in a heartbeat.

Thanks to Mek and Tosj for an excellent product so far - I'm eager to watch it improve.

First of all, kudos to the development team.  Very little software makes it through my filter into the possibility of regular use.  I probably demo 50 for any one I actually use.

I'm a LaTeX user now for 20 some years.  My current bibtex file has, let's see
[26] % grep \@ Boker01.bib | wc
    1614    1614   34777
1614 entries.  I publish in Psychology and Computer Science. 

Bibdesk did not make the threshold for use for me.  Papers looks like it will.  I have trouble trusting my bibtex file to anything but a plain text editor due to the ever-evolving nature of the software industry.  Think about it, what other file would make the transition from late 80s to now without needing to redo the work?  I'd like to still be building on my previous work in another 20 years.

For this reason, I expect to continue keeping the final copy of my bibtex entries in a plain text file.  The fact that Papers keeps its pdfs in an organized directory tree is an enormous advantage to the long term viability of my personal archive.  I have colleagues who have used wonderful products in the past who, 10 or 15 years later, can no longer access those wonderful files.

So, given that, even if Papers were an all-in-one bibdesk and pdf organizer, I would only use it that way if it were keeping its archives in plain text bibtex and directory structures.  That would be limiting and I doubt that the developer team would take that route, but in order for me to feel safe in entrusting my time to this program, I'd need to know that if the developers get tired of supporting Papers in 10 years, I won't have a big chunk of my work locked up in it.

So, I expect I'll just use Papers for what the authors originally intended, and not for a bibtex organizer.  For my workflow it would be very helpful if Papers could implement the copy/paste solution for bibtex entries.  I was looking for how to do this when I came to help center.  I can make a temporary text file with a single entry and import or I can export a temporary text file with a single entry and then copy and paste that to a bibtex file.  But doing that directly from the pasteboard would speed things up considerably.

There is one other feature that would be useful.  Suppose I have an existing bibtex entry imported into Papers and an existing pdf imported into Papers.  I'd like to be able to associate them with each other.  Or perhaps, be able to paste a bibtex entry or search a bibtex file during a "Match" operation.

Well, I guess a little revitalization of this topic maybe in order. In our lab I promoted papers to our principal investigator and suggested getting a license for papers for all our users. He got the thing and is tremendously happy with it (which i understand, since he came from the unbearable Endnote world). But when i suggested that for a particular task we would have to employ bibdesk, he retorted: "I don't want to install multiple reference managers in my computer". So in his mind, Bibdesk and papers address the same problem space, and Papers should be the final solution.
With which I agree wholeheartedly. But then again, that would demand papers adding some of Bibdesk functionality.

In essence: this post is wanting to backup the previous posts. Papers should be a superset of bibdesk and not only partially overlapping.

Full disclosure: I'm one of the BibDesk developers, and lurk here out of curiosity.

From a development perspective, it has taken years to achieve the present level of BibTeX support in BibDesk, and that is with  developers (and most users) of BibDesk who are solely interested in BibTeX support.  In my opinion, BibDesk has an advantage over Papers in this respect, since the primary storage is BibTeX, and it's easier to clean BibTeX up and make it human-readable than it is to go the other way.  It's great that Mek is trying to improve this in Papers, but I'd like to add a few comments.

BibTeX itself does not have a well-defined grammar (except the WEB source), and allows variations in syntax that are truly a nightmare.  Gerd Neugebauer's BibTool, Greg Ward's btparse, and Nelson Beebe's bibclean are probably the most robust tools for handling it, since it takes great care to ensure round-trip fidelity through a program without data loss (guess how many users were enraged when they saved a file after BibDesk expanded macros or screwed up escaping %?).

For example, there are idiosyncrasies for things like cite keys, in that non-ASCII characters (and even some ASCII characters) must not be used in a key, or TeX itself will choke.  Multibyte encodings such as UTF-8 are problematic for some bib styles, so you really need to convert non-ASCII characters to TeX commands; this code in BibDesk is very complicated, since it converts both ways.  BibTeX also has various special features like macros and crossrefs, which have distinct advantages when used with LaTeX, but were very difficult to support properly in a user interface, even one designed around BibTeX. 

All of this code is specifically for BibTeX, too, and it constrains an application's feature set and can make future refactoring or features a complete nightmare (been there, done that).  So my advice to Mek is to be cautious in implementing BibTeX-specific features.  Supporting BibTeX can be a huge can of worms, and users are never satisfied .

Mek, feel free to e-mail me (amaxwell at mac dot com) if you have questions on specifics of how BibDesk does stuff, or if there are problems interacting with it.  Also, I suspect there may be some macro expansion issues in the code I sent you long ago for working with btparse...but I never got around to checking it more thoroughly.

I don't use Papers myself, so I'm not a great candidate for testing (and I don't know what the current level of support for BibTeX is).  There are a number of critical things, here in roughly decreasing order of importance.  Bear in mind that these are my opinions, of course, so my advice is worth about what you paid for it .

1) Citekeys (if automatically generated) must be deterministic; if they change between exports, you break existing LaTeX papers!
2) BibTeX needs multiple types; an early complaint I heard about Papers was that only @article was supported, but maybe it's resolved now?
3) Within those types, required/optional fields should be defined as specified in btxdoc
4) Conversion of non-ASCII characters to TeX command sequences, e.g., ü --> {\" u} (BibDesk's BDSKConverter for this could probably be used almost as-is)
5) Other types should be allowed, since original BibTeX doesn't have all types needed these days, but I'd avoid going down the path of defining and validating them formally

Dealing with user-defined types and field sets for validation is very complicated.  Same problem for custom character conversions.  I'd avoid that if possible.  I'm not even sure how you'd handle the former with Core Data modeling...

Allowing too many options for citekeys is also problematic, in view of the validation required.  People ask for the ability to specify stuff like "first 4 characters of the second author's last name + first word of title or book title + year + first author's sister's cat's grandmother's name."  This leads to madness!  Christiaan Hofman has done a great job with allowing customization of these in BibDesk, but regularly has to turn down requests for more options.  When all is said and done, it just needs to be unique.  This can be a problem when sharing or merging BibTeX files, but for something specialized like that, use BibDesk or BibTool, which have code to deal with merging and finding duplicates.