Re: [Bibdesk-users] reorganizing local files
On Jan 13, 2008, at 8:26 PM, P Kishor wrote: > Of course, I am also discovering (new to me) features, and I have a > question re. one of them. I checked for orphan files, found a few, and > then discovered in Prefs that I can set the name of the local files as > they are filed away in the repository folder. So, I decided to set > that to > > %a1/%Y/%t30(%u2)%e > > which should make a file look like > > "~/Documents/BibDesk/McCracken/2004/BibDesk, a great application > t(aa).pdf" > > I thought that, iTunes like, BD would reorganize my AutoFile folder, > neatly creating the requisite folder hierarchy and storing everything > accordingly. Of course, no such thing happened. Was my expectation > wrong? Yes. > Does this apply only the "future" files added to the > collection? You can force it to move existing linked files using Publication -> Consolidate Linked Files. I recommend searching the help book for "autofile" which should give you plenty of information. -- adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] reorganizing local files
I have been using 1.3.13, and maybe it is just me not pushing the envelope much but I haven't experienced any of the problems or issues mentioned by some folks on the list. Other than being able to see the local attached file in the vertical pane to the right, frankly, the program still looks as it was earlier -- really good, and not much changed ( turned the right pane off, and continue to read the PDF in the pane below the list of the publications, much like the traditional 3-pane view of Apple's Mail.app). The program offered to do the conversion of the local repo, and then did nothing, so I figured there was nothing funky about my repository. Of course, I am also discovering (new to me) features, and I have a question re. one of them. I checked for orphan files, found a few, and then discovered in Prefs that I can set the name of the local files as they are filed away in the repository folder. So, I decided to set that to %a1/%Y/%t30(%u2)%e which should make a file look like "~/Documents/BibDesk/McCracken/2004/BibDesk, a great application t(aa).pdf" I thought that, iTunes like, BD would reorganize my AutoFile folder, neatly creating the requisite folder hierarchy and storing everything accordingly. Of course, no such thing happened. Was my expectation wrong? Does this apply only the "future" files added to the collection? -- Puneet Kishor - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] this is not important except to the obsessively detail-oriented
On Jan 13, 2008, at 7:19 PM, Derick Fay wrote: > If you right-click on a group, whether it's smart or static, the > option in the context menu is "Remove Smart Group". Changed to "Remove Group" in the next nightly. We probably changed the title based on selection at some point, but most of the excessively dynamic menus are gone. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] this is not important except to the obsessively detail-oriented
If you right-click on a group, whether it's smart or static, the option in the context menu is "Remove Smart Group". - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] Book-related Applescripts Updated for 1.3.13
I've updated my book AppleScripts to version 0.4.3 to fix the problems with 1.3.13 and problems with WorldCat. These scripts search WorldCat, Amazon, and the Library of Congress, offering a quick way of fixing existing book cites or adding new ones. All are available at http://people.reed.edu/~ahm/Projects/Citation/BibDesk/ There are three locator scripts (WorldCat, ECampus, and Amazon), a script to add WorldCat URLs, and three scripts to quickly fix and/or add books to your library. The README for the latter is below. -AHM -- --BookScripts --Version 0.4.3 2008-01-13 Fixes for 1.3.13, see individual scripts for changes --Version 0.4.2 2007-05-21 Fixes for incollection, keeping searched ISBNs, title to booktitle --Version 0.4.1 2007-05-07 Fixed WorldCat, Reduced number of hard- coded results to 3 from 10 --Version 0.4.0 2007-03-26 Added WorldCat, SearchOrder, ISBN13 to ISBN10 conversion --Version 0.3.1 2007-02-07 Fix for Add to ISBN script --Version 0.3.0 2007-01-15 First public release --Comments to [EMAIL PROTECTED] This script suite contains three scripts for pulling down book information from the Library of Congress, WorldCat, or Amazon to BibDesk. WARNING: Use at your own risk. Always make a backup copy of your data before using these scripts. Installation: 1)Place all files in the "Put in ~/Library/Application Support/BibDesk/ Scripts" folder in ~/Library/Application Support/BibDesk/Scripts/ 2)Place all files in the "Put in ~/Library/ScriptingAdditions" folder in ~/Library/ScriptingAdditions Book Add by ISBN.scpt --Gets the WorldCat/Library of Congress/Amazon (checks in order SearchOrder) entry from your ISBN and adds the book to the front window's database Book Add from Amazon.scpt --Gets the Amazon entry from your search, gives you a list of books, then adds the selected book(s) to the front window's database Book Cite Fixer.scpt --To try to fix the cites of the selected books, run the "Book Cite Fixer" script on your books that have fields filled in. Entry types other than "book," "inbook," or "incollection" are presently ignored. If multiple entries are found, it will give you a list of the entries (up to 3 currently, settable by property maxResults); after selecting an entry, it will give you a list of fields to fill in. Note that you can use this as a way of searching WorldCat/Library of Congress/ Amazon; open a new entry, fill in a couple of fields (don't forget to tab out!), then run the script to fill the rest of the fields. It checks in order SearchOrder. --To match better, it only looks in five fields. If an ISBN is found, it searches on the first 10 or 13 characters of the ISBN (checks for 13 first); otherwise, it uses title, editor, author, and year. Titles are restricted to the first part (before a : or ;), it uses the last name of the first author, and tries to get the first name of the editor if it exists (everything before the first comma). Book Locator Amazon.scpt --Dependency on BookLib removed in 0.4.0, available as a separate download. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] download pdf script broken
Fixed version is now up. See Article JSTOR Download.scpt at: http://people.reed.edu/~ahm/Projects/Citation/BibDesk/ -AHM On 2008-01-13, at 10:22 AM, Alexander H. Montgomery wrote: > It accesses the URL via > > set theURL to the value of field "URL" of thePub > > which needs to be changed to > > set theURL to linked URL 1 of thePub > > I'm in the process of fixing my scripts to work with 1.3.13 properly. > > -AHM > > On 2008-01-13, at 10:12 AM, Christiaan Hofman wrote: > >> I don't know why, but it may be related to the new file layout. This >> is also reflected in the AppleScript support. E.g. 'local file' and >> 'remote URL' are now deprecated, and they refer now to the first >> linked file and URL from the new file layout rather than the Local- >> Url and Url fields. >> >> Christiaan >> >> On 13 Jan 2008, at 6:31 PM, Nicholas Cole wrote: >> >>> Dear All, >>> >>> Does anyone else find that the new release has broken the "JSTOR >>> Download PDF" script from [EMAIL PROTECTED] >>> >>> If so, does anyone know why? >>> >>> Best wishes, >>> >>> Nicholas >>> >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> ___ >> Bibdesk-users mailing list >> Bibdesk-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users >> > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Bibdesk-users Digest, Vol 21, Issue 21
I use the cite key as the local file name, so my custom file format
string was simply "%f{Cite Key}"... but now 1.3.13 says that this
is
invalid because "Format for local file requires a unique
specifier."
I'm fairly certain that cite keys are required to be unique, so I
think this is a bug. Thoughts?
>>>
>>> Cite keys should be unique within a document, but it's not
>>> guaranteed. AutoFile needs a specifier that lets it create a unique
>>> filename on disk, since the filenames on your disk are independent
>>> of
>>> your document and cite keys.
>>
>> I suppose that this is a lengthy way of asking, "Is there any way to
>> have the cite key and the file name be the same?"
> Yes and no. See also my other post. Note that the cite key generated
> this way is unique *for the publication*, but for files it has to be
> unique *for the file* (on disk). These are different requirements, in
> particular now that a publication can have several files. Just use "%f
> {Cite Key}%u0%e". This will most of the time create a file with the
> same name as the cite key, but if necessary (and only if necessary)
> makes it unique. And you'd want that anyway to avoid overwriting a
> file.
>
> Christiaan
Ah, interesting. I was not aware that "%u0" was an option... I
assumed X had to be greater than 0 in the "%uX" expression. This is
perhaps not as clear as it could be in the help files.
Thanks!
Best, Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On Jan 13, 2008, at 2:33 PM, Holger Frauenrath wrote: >> I don't understand this complaint (and regardless of the disclaimer >> below, it is a complaint). How could you see the PDF file before >> without selecting or opening it? If you're thinking of drag-and-drop >> from the main table, add a "Local File" column and drag the paperclip >> or click on it. > > I did not know this was possible now. As I said ... I have not had the > time to take a detailed look at the new version. We added that a couple weeks ago after users requested the ability to sort and see at a glance which entries had files associated. Same thing exists for URLs, and I prefer it to the old system. As during nightly build testing, I'd strongly urge people to try it out for a while before lamenting the apparent loss of features! >>> Don't get me wrong: this is not a complaint. I followed the previous >>> discussion and decided to stay quiet - so that's "my own fault". > >> If people on this list ignored the discussion over the last 4 months >> we've been working on this and did not test the nightly builds, that >> is your own fault. > > That is what I said. I know; that was mainly for the rest of the people on the list who stayed quiet :). regards, adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
Hi Adam, > I don't understand this complaint (and regardless of the disclaimer > below, it is a complaint). How could you see the PDF file before > without selecting or opening it? If you're thinking of drag-and-drop > from the main table, add a "Local File" column and drag the paperclip > or click on it. I did not know this was possible now. As I said ... I have not had the time to take a detailed look at the new version. >> Don't get me wrong: this is not a complaint. I followed the previous >> discussion and decided to stay quiet - so that's "my own fault". > If people on this list ignored the discussion over the last 4 months > we've been working on this and did not test the nightly builds, that > is your own fault. That is what I said. > Frankly, I'd suggest that the only place you'll > find sympathy is in the dictionary... :) I have plenty things that give me pleasure. :-) Best regards Holger - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
Hi Christiaan > First of all: there *is* a definite need for it now, because it is > *possible* to add more than one files to an item, which all can be > auto-filed (the word 'possible' is crucial). So you need a way to > make the name unique, otherwise they would overwrite each other. It > is just a consequence of the new possibility. I have a naming scheme "author+year+short journal+pages". This is a *systematic naming scheme, and it is unique for my PDF files (I see that it would not be in case I had more than one file per reference). My label is the same as my PDFfile name, as in the case of the original poster. > It will *not* break your old naming scheme, it just has to be > modified a little bit. > In most cases when you already have a format that works, the only > thing you'd want to do is add a "%u0" of "%n0" just before the file > extension (I recommend your format always to end with "%u0%e" or "%n0% > e"). This will use your old scheme when possible, but creates unique > file names when needed. Okay, I did not know this detail. I assumed that a unique letter would always be added. This would not be acceptable because the above naming scheme is used by all of my group members, in BibTeX/LaTeX, in Word/ Endnote, and for saving PDF files of literature to our group partition on the server; so it needs to be systematic (and should not rely on unique letters). Holger __ Dr. Holger Frauenrath ETH Zurich Department of Materials Wolfgang-Pauli-Str. 10, HCI H515 CH-8093 Zurich Switzerland Phone: (+41) 44 633 6474 Fax: (+41) 44 633 1390 Email: [EMAIL PROTECTED] Web: http://www.polychem.mat.ethz.ch/frauenrath/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On 13 Jan 2008, at 11:17 PM, Christopher MacMinn wrote:
>>> I use the cite key as the local file name, so my custom file format
>>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>>> invalid because "Format for local file requires a unique specifier."
>>> I'm fairly certain that cite keys are required to be unique, so I
>>> think this is a bug. Thoughts?
>>
>> Cite keys should be unique within a document, but it's not
>> guaranteed. AutoFile needs a specifier that lets it create a unique
>> filename on disk, since the filenames on your disk are independent of
>> your document and cite keys.
>
> Hm. So here's my problem -- for cite keys, I use something like
> "first author's last name"-"journal"-"year" followed by a lowercase
> letter if necessary for uniqueness. I can't auto-generate them
> because I use my own quirky abbreviations for journal names (e.g.,
> "Journal of Fluid Mechanics" is "jfm", but "Annual Review of Fluid
> Mechanics" is "annrevfm"). Each cite key is unique, so I use them as
> autofile specifiers and all of my references live happily in a single
> folder on my disk. Is there any way to achieve this in 1.3.13?
>
Yes and no. See also my other post. Note that the cite key generated
this way is unique *for the publication*, but for files it has to be
unique *for the file* (on disk). These are different requirements, in
particular now that a publication can have several files. Just use "%f
{Cite Key}%u0%e". This will most of the time create a file with the
same name as the cite key, but if necessary (and only if necessary)
makes it unique. And you'd want that anyway to avoid overwriting a file.
Christiaan
> I suppose that this is a lengthy way of asking, "Is there any way to
> have the cite key and the file name be the same?"
>
>> I think there was a post on this yesterday as well.
>
> Yes, I see that now -- sorry I missed it. I apologize for the
> overlap.
>
>
> Thanks very much for your help.
>
> Best, Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On Jan 13, 2008, at 1:57 PM, Holger Frauenrath wrote: > > On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote: > >> Cite keys should be unique within a document, but it's not >> guaranteed. AutoFile needs a specifier that lets it create a unique >> filename on disk, since the filenames on your disk are independent of >> your document and cite keys. >> >> I think there was a post on this yesterday as well. > > > I know that this is intended (new) behavior. But it also breaks my old > and proven naming scheme for the PDF files (I only have PDF files > attached to all references; therefore, there is no need for a "unique > identifier" as part of the label name or file name) in the same way it > does for the original poster and, as a matter of fact my whole way of > dealing with the PDF files. The fact that they're all PDF files is irrelevant. The unique specifier is only added if a file with the newly generated name already exists on disk; if your filenames are unique already, as you say, you won't notice a difference. > I have not had the time to look at the new > version in detail (and probably will not have it in the near future) > in order to find out how I can adapt my established to the new way of > dealing with files. I must admit that I also do not like the fact that > I have to select a reference now in order to see the PDF file and be > able to click on it. I don't understand this complaint (and regardless of the disclaimer below, it is a complaint). How could you see the PDF file before without selecting or opening it? If you're thinking of drag-and-drop from the main table, add a "Local File" column and drag the paperclip or click on it. > Don't get me wrong: this is not a complaint. I followed the previous > discussion and decided to stay quiet - so that's "my own fault". > > I just wanted to explain why I think that several other people are > going to bring up problems like the one above, be it intended behavior > or not. If people on this list ignored the discussion over the last 4 months we've been working on this and did not test the nightly builds, that is your own fault. Frankly, I'd suggest that the only place you'll find sympathy is in the dictionary... :) -- adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On 13 Jan 2008, at 10:57 PM, Holger Frauenrath wrote:
>
> On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote:
>
>>
>> On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:
>>
>>> Hey folks -
>>>
>>> I just installed BibDesk version 1.3.13, and it's giving me a hard
>>> time about the "local file format" I've been using for autofile. I
>>> use the cite key as the local file name, so my custom file format
>>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>>> invalid because "Format for local file requires a unique specifier."
>>> I'm fairly certain that cite keys are required to be unique, so I
>>> think this is a bug. Thoughts?
>>
>> Cite keys should be unique within a document, but it's not
>> guaranteed. AutoFile needs a specifier that lets it create a unique
>> filename on disk, since the filenames on your disk are independent of
>> your document and cite keys.
>>
>> I think there was a post on this yesterday as well.
>
>
> I know that this is intended (new) behavior. But it also breaks my old
> and proven naming scheme for the PDF files (I only have PDF files
> attached to all references; therefore, there is no need for a "unique
> identifier" as part of the label name or file name) in the same way it
> does for the original poster and, as a matter of fact my whole way of
> dealing with the PDF files. I have not had the time to look at the new
> version in detail (and probably will not have it in the near future)
> in order to find out how I can adapt my established to the new way of
> dealing with files. I must admit that I also do not like the fact that
> I have to select a reference now in order to see the PDF file and be
> able to click on it.
>
> Don't get me wrong: this is not a complaint. I followed the previous
> discussion and decided to stay quiet - so that's "my own fault".
>
> I just wanted to explain why I think that several other people are
> going to bring up problems like the one above, be it intended behavior
> or not.
>
> Best regards
> Holger
>
First of all: there *is* a definite need for it now, because it is
*possible* to add more than one files to an item, which all can be
auto-filed (the word 'possible' is crucial). So you need a way to
make the name unique, otherwise they would overwrite each other. It
is just a consequence of the new possibility.
It will *not* break your old naming scheme, it just has to be
modified a little bit.
In most cases when you already have a format that works, the only
thing you'd want to do is add a "%u0" of "%n0" just before the file
extension (I recommend your format always to end with "%u0%e" or "%n0%
e"). This will use your old scheme when possible, but creates unique
file names when needed.
Christiaan
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
>> I use the cite key as the local file name, so my custom file format
>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>> invalid because "Format for local file requires a unique specifier."
>> I'm fairly certain that cite keys are required to be unique, so I
>> think this is a bug. Thoughts?
>
> Cite keys should be unique within a document, but it's not
> guaranteed. AutoFile needs a specifier that lets it create a unique
> filename on disk, since the filenames on your disk are independent of
> your document and cite keys.
Hm. So here's my problem -- for cite keys, I use something like
"first author's last name"-"journal"-"year" followed by a lowercase
letter if necessary for uniqueness. I can't auto-generate them
because I use my own quirky abbreviations for journal names (e.g.,
"Journal of Fluid Mechanics" is "jfm", but "Annual Review of Fluid
Mechanics" is "annrevfm"). Each cite key is unique, so I use them as
autofile specifiers and all of my references live happily in a single
folder on my disk. Is there any way to achieve this in 1.3.13?
I suppose that this is a lengthy way of asking, "Is there any way to
have the cite key and the file name be the same?"
> I think there was a post on this yesterday as well.
Yes, I see that now -- sorry I missed it. I apologize for the overlap.
Thanks very much for your help.
Best, Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On Jan 13, 2008, at 10:43 PM, Adam R. Maxwell wrote:
>
> On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:
>
>> Hey folks -
>>
>> I just installed BibDesk version 1.3.13, and it's giving me a hard
>> time about the "local file format" I've been using for autofile. I
>> use the cite key as the local file name, so my custom file format
>> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
>> invalid because "Format for local file requires a unique specifier."
>> I'm fairly certain that cite keys are required to be unique, so I
>> think this is a bug. Thoughts?
>
> Cite keys should be unique within a document, but it's not
> guaranteed. AutoFile needs a specifier that lets it create a unique
> filename on disk, since the filenames on your disk are independent of
> your document and cite keys.
>
> I think there was a post on this yesterday as well.
I know that this is intended (new) behavior. But it also breaks my old
and proven naming scheme for the PDF files (I only have PDF files
attached to all references; therefore, there is no need for a "unique
identifier" as part of the label name or file name) in the same way it
does for the original poster and, as a matter of fact my whole way of
dealing with the PDF files. I have not had the time to look at the new
version in detail (and probably will not have it in the near future)
in order to find out how I can adapt my established to the new way of
dealing with files. I must admit that I also do not like the fact that
I have to select a reference now in order to see the PDF file and be
able to click on it.
Don't get me wrong: this is not a complaint. I followed the previous
discussion and decided to stay quiet - so that's "my own fault".
I just wanted to explain why I think that several other people are
going to bring up problems like the one above, be it intended behavior
or not.
Best regards
Holger
__
Dr. Holger Frauenrath
ETH Zurich
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zurich
Switzerland
Phone: (+41) 44 633 6474
Fax: (+41) 44 633 1390
Email: [EMAIL PROTECTED]
Web: http://www.polychem.mat.ethz.ch/frauenrath/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] Autofile problems with 1.3.13
On Jan 13, 2008, at 1:30 PM, Christopher MacMinn wrote:
> Hey folks -
>
> I just installed BibDesk version 1.3.13, and it's giving me a hard
> time about the "local file format" I've been using for autofile. I
> use the cite key as the local file name, so my custom file format
> string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
> invalid because "Format for local file requires a unique specifier."
> I'm fairly certain that cite keys are required to be unique, so I
> think this is a bug. Thoughts?
Cite keys should be unique within a document, but it's not
guaranteed. AutoFile needs a specifier that lets it create a unique
filename on disk, since the filenames on your disk are independent of
your document and cite keys.
I think there was a post on this yesterday as well.
--
adam
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] Autofile problems with 1.3.13
Hey folks -
I just installed BibDesk version 1.3.13, and it's giving me a hard
time about the "local file format" I've been using for autofile. I
use the cite key as the local file name, so my custom file format
string was simply "%f{Cite Key}"... but now 1.3.13 says that this is
invalid because "Format for local file requires a unique specifier."
I'm fairly certain that cite keys are required to be unique, so I
think this is a bug. Thoughts?
Thanks!
Best, Chris MacMinn
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On 13 Jan 2008, at 9:43 PM, Adam R. Maxwell wrote: > > On Jan 13, 2008, at 12:35 PM, Christiaan Hofman wrote: > >> >> On 13 Jan 2008, at 9:29 PM, Adam R. Maxwell wrote: >> >>> >>> On Jan 13, 2008, at 12:21 PM, Christiaan Hofman wrote: >>> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: > Is there any possibility in a future version of caching the index > of > the content of related files so it doesn't need to be recreated > each > time? > > df This has been discussed before on this list. a problem is that BibDesk does not have a single database, so any cached index somehow needs to be associated to a .bib file. This association is necessarily weak and fragile. And as a bibtex file can easily be added as a plain text file or any other bibtex editor, the index may easily get invalid. Therefore it makes caching the index very fragile, you could easily get an invalid cached index. If we can find solutions to these problems we might in the future do this. >>> >>> Another problem is that we just introduced aliases, so you can move >>> your files around in Finder without breaking BibDesk, but that would >>> invalidate the index (and we have no way of monitoring those >>> changes, >>> since your files can be anywhere). I casually watch the Papers >>> support forum and their index maintenance seems to be a persistent >>> headache. >>> >>> -- >>> adam >>> >> >> Of course that applies even without caching. Though caching would >> aggravate the problem, because simply reopening the document wouldn't >> fix it. > > Quite right. Of course, a manual method could be added to nuke the > cache, but that's not very gratifying. Could linked files post a > notification when they update the alias? Even that wouldn't tell us > which file(s) in the index were bad, so the whole thing would have to > be rebuilt. I'm not sure. It would require the linked file object to cache the last URL to compare any changes. Moreover files that are not displayed may not be triggered to check whether they're changed. And most of the time the alias won't be updated, as the FSRef is used. So then this would not even be relevant, I think. Of course it would be irrelevant for cached indexes. Perhaps a cached index could also contain a list of publications and their URLs to compare and see if items in the cached index have to be updated. Christiaan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008, at 3:34 PM, Adam R. Maxwell wrote: > > On Jan 13, 2008, at 12:25 PM, Niels Kobschaetzki wrote: > >> On Jan 13, 2008 9:21 PM, Christiaan Hofman <[EMAIL PROTECTED]> >> wrote: >>> >>> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: >>> Is there any possibility in a future version of caching the index of the content of related files so it doesn't need to be recreated each time? df >>> >>> This has been discussed before on this list. a problem is that >>> BibDesk does not have a single database, so any cached index somehow >>> needs to be associated to a .bib file. This association is >>> necessarily weak and fragile. And as a bibtex file can easily be >>> added as a plain text file or any other bibtex editor, the index may >>> easily get invalid. Therefore it makes caching the index very >>> fragile, you could easily get an invalid cached index. If we can >>> find >>> solutions to these problems we might in the future do this. >> >> Can't you just put a time stamp and maybe a hash-value of the file >> for >> identification in the index, compare that to the associated file when >> it's opened and if the stuff doesn't fit re-index occurs on opening >> the file? >> This would cut down indexing at least a little bit, wouldn't it? > > I'd actually planned to do something like that by now (storing the mod > date of the file and an alias to it with the search index cache, which > would be a pretty good link between document and cache). The > documents are stored as URLs inside the index, though, and we don't > have a good way to work around that aspect of the fragility at this > time. How expensive is hashing the .bib file? If it's quick, you could imagine storing the hash with the index whenever the .bib file is saved. When a .bib file is opened, you could regenerate the hash and use it as a key to find the appropriate index. Sorry if this is naive. Jim Harrison UVa - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008, at 12:35 PM, Christiaan Hofman wrote: > > On 13 Jan 2008, at 9:29 PM, Adam R. Maxwell wrote: > >> >> On Jan 13, 2008, at 12:21 PM, Christiaan Hofman wrote: >> >>> >>> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: >>> Is there any possibility in a future version of caching the index of the content of related files so it doesn't need to be recreated each time? df >>> >>> This has been discussed before on this list. a problem is that >>> BibDesk does not have a single database, so any cached index somehow >>> needs to be associated to a .bib file. This association is >>> necessarily weak and fragile. And as a bibtex file can easily be >>> added as a plain text file or any other bibtex editor, the index may >>> easily get invalid. Therefore it makes caching the index very >>> fragile, you could easily get an invalid cached index. If we can >>> find >>> solutions to these problems we might in the future do this. >> >> Another problem is that we just introduced aliases, so you can move >> your files around in Finder without breaking BibDesk, but that would >> invalidate the index (and we have no way of monitoring those changes, >> since your files can be anywhere). I casually watch the Papers >> support forum and their index maintenance seems to be a persistent >> headache. >> >> -- >> adam >> > > Of course that applies even without caching. Though caching would > aggravate the problem, because simply reopening the document wouldn't > fix it. Quite right. Of course, a manual method could be added to nuke the cache, but that's not very gratifying. Could linked files post a notification when they update the alias? Even that wouldn't tell us which file(s) in the index were bad, so the whole thing would have to be rebuilt. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008 9:31 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: > > > On 13 Jan 2008, at 9:25 PM, Niels Kobschaetzki wrote: > > > On Jan 13, 2008 9:21 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: > >> > >> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: > >> > >>> Is there any possibility in a future version of caching the index of > >>> the content of related files so it doesn't need to be recreated each > >>> time? > >>> > >>> df > >> > >> This has been discussed before on this list. a problem is that > >> BibDesk does not have a single database, so any cached index somehow > >> needs to be associated to a .bib file. This association is > >> necessarily weak and fragile. And as a bibtex file can easily be > >> added as a plain text file or any other bibtex editor, the index may > >> easily get invalid. Therefore it makes caching the index very > >> fragile, you could easily get an invalid cached index. If we can find > >> solutions to these problems we might in the future do this. > > > > Can't you just put a time stamp and maybe a hash-value of the file for > > identification in the index, compare that to the associated file when > > it's opened and if the stuff doesn't fit re-index occurs on opening > > the file? > > This would cut down indexing at least a little bit, wouldn't it? > > > > Niels > > > > A time stamp would almost certainly be a requirement for this. But > the .bib file when opened should somehow be able to find back it's > corresponding cached index before it can even compare anything. And > of course after deciding about how to do all this, it has to be > implemented by someone... I have no idea about the cache but I guess that this is in a fixed location. Check the hash (MD5?) of the bib-file against a hash-table in which hashes are "noted down" and linked to corresponding indexes. Then you wouldn't even have to worry about the location of the bib-file and the time-stamp because e.g. MD5-hashes are supposed to be nearly unique (and you do not have to worry about forged MD5-hashes because nobody would be interested to forge the MD5-hash of his bib-file…but if you are afraid of errors regarding this…well, then it would be a problem for sure) Niels - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On 13 Jan 2008, at 9:29 PM, Adam R. Maxwell wrote: > > On Jan 13, 2008, at 12:21 PM, Christiaan Hofman wrote: > >> >> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: >> >>> Is there any possibility in a future version of caching the index of >>> the content of related files so it doesn't need to be recreated each >>> time? >>> >>> df >> >> This has been discussed before on this list. a problem is that >> BibDesk does not have a single database, so any cached index somehow >> needs to be associated to a .bib file. This association is >> necessarily weak and fragile. And as a bibtex file can easily be >> added as a plain text file or any other bibtex editor, the index may >> easily get invalid. Therefore it makes caching the index very >> fragile, you could easily get an invalid cached index. If we can find >> solutions to these problems we might in the future do this. > > Another problem is that we just introduced aliases, so you can move > your files around in Finder without breaking BibDesk, but that would > invalidate the index (and we have no way of monitoring those changes, > since your files can be anywhere). I casually watch the Papers > support forum and their index maintenance seems to be a persistent > headache. > > -- > adam > Of course that applies even without caching. Though caching would aggravate the problem, because simply reopening the document wouldn't fix it. Christiaan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008, at 12:25 PM, Niels Kobschaetzki wrote: > On Jan 13, 2008 9:21 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: >> >> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: >> >>> Is there any possibility in a future version of caching the index of >>> the content of related files so it doesn't need to be recreated each >>> time? >>> >>> df >> >> This has been discussed before on this list. a problem is that >> BibDesk does not have a single database, so any cached index somehow >> needs to be associated to a .bib file. This association is >> necessarily weak and fragile. And as a bibtex file can easily be >> added as a plain text file or any other bibtex editor, the index may >> easily get invalid. Therefore it makes caching the index very >> fragile, you could easily get an invalid cached index. If we can find >> solutions to these problems we might in the future do this. > > Can't you just put a time stamp and maybe a hash-value of the file for > identification in the index, compare that to the associated file when > it's opened and if the stuff doesn't fit re-index occurs on opening > the file? > This would cut down indexing at least a little bit, wouldn't it? I'd actually planned to do something like that by now (storing the mod date of the file and an alias to it with the search index cache, which would be a pretty good link between document and cache). The documents are stored as URLs inside the index, though, and we don't have a good way to work around that aspect of the fragility at this time. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On 13 Jan 2008, at 9:25 PM, Niels Kobschaetzki wrote: > On Jan 13, 2008 9:21 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: >> >> On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: >> >>> Is there any possibility in a future version of caching the index of >>> the content of related files so it doesn't need to be recreated each >>> time? >>> >>> df >> >> This has been discussed before on this list. a problem is that >> BibDesk does not have a single database, so any cached index somehow >> needs to be associated to a .bib file. This association is >> necessarily weak and fragile. And as a bibtex file can easily be >> added as a plain text file or any other bibtex editor, the index may >> easily get invalid. Therefore it makes caching the index very >> fragile, you could easily get an invalid cached index. If we can find >> solutions to these problems we might in the future do this. > > Can't you just put a time stamp and maybe a hash-value of the file for > identification in the index, compare that to the associated file when > it's opened and if the stuff doesn't fit re-index occurs on opening > the file? > This would cut down indexing at least a little bit, wouldn't it? > > Niels > A time stamp would almost certainly be a requirement for this. But the .bib file when opened should somehow be able to find back it's corresponding cached index before it can even compare anything. And of course after deciding about how to do all this, it has to be implemented by someone... Christiaan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008, at 12:21 PM, Christiaan Hofman wrote: > > On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: > >> Is there any possibility in a future version of caching the index of >> the content of related files so it doesn't need to be recreated each >> time? >> >> df > > This has been discussed before on this list. a problem is that > BibDesk does not have a single database, so any cached index somehow > needs to be associated to a .bib file. This association is > necessarily weak and fragile. And as a bibtex file can easily be > added as a plain text file or any other bibtex editor, the index may > easily get invalid. Therefore it makes caching the index very > fragile, you could easily get an invalid cached index. If we can find > solutions to these problems we might in the future do this. Another problem is that we just introduced aliases, so you can move your files around in Finder without breaking BibDesk, but that would invalidate the index (and we have no way of monitoring those changes, since your files can be anywhere). I casually watch the Papers support forum and their index maintenance seems to be a persistent headache. -- adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On Jan 13, 2008 9:21 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: > > On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: > > > Is there any possibility in a future version of caching the index of > > the content of related files so it doesn't need to be recreated each > > time? > > > > df > > This has been discussed before on this list. a problem is that > BibDesk does not have a single database, so any cached index somehow > needs to be associated to a .bib file. This association is > necessarily weak and fragile. And as a bibtex file can easily be > added as a plain text file or any other bibtex editor, the index may > easily get invalid. Therefore it makes caching the index very > fragile, you could easily get an invalid cached index. If we can find > solutions to these problems we might in the future do this. Can't you just put a time stamp and maybe a hash-value of the file for identification in the index, compare that to the associated file when it's opened and if the stuff doesn't fit re-index occurs on opening the file? This would cut down indexing at least a little bit, wouldn't it? Niels - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] cache index?
On 11 Jan 2008, at 7:14 PM, Derick Fay wrote: > Is there any possibility in a future version of caching the index of > the content of related files so it doesn't need to be recreated each > time? > > df This has been discussed before on this list. a problem is that BibDesk does not have a single database, so any cached index somehow needs to be associated to a .bib file. This association is necessarily weak and fragile. And as a bibtex file can easily be added as a plain text file or any other bibtex editor, the index may easily get invalid. Therefore it makes caching the index very fragile, you could easily get an invalid cached index. If we can find solutions to these problems we might in the future do this. Christiaan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] website updates
Anyone with web skills want to update our web page? If we get a few volunteers, that might make it easier. Some things I noticed: - Some (all?) screenshots are now outdated. - The only thing I can find that alludes to file/link management is "...BibDesk also keeps track of electronic copies of literature on your computer." - The import/export sections are also shockingly outdated - Even http://en.wikipedia.org/wiki/BibDesk and http://en.wikipedia.org/wiki/Comparison_of_reference_management_software have a more current feature listing. Suggestions? We talked about moving it all to the wiki at some point, but I'm not sure if that's feasible, and it also has too many distracting wiki-isms for a home page. Moving the feature lists and screenshots there might be good. adam - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] download pdf script broken
It accesses the URL via set theURL to the value of field "URL" of thePub which needs to be changed to set theURL to linked URL 1 of thePub I'm in the process of fixing my scripts to work with 1.3.13 properly. -AHM On 2008-01-13, at 10:12 AM, Christiaan Hofman wrote: > I don't know why, but it may be related to the new file layout. This > is also reflected in the AppleScript support. E.g. 'local file' and > 'remote URL' are now deprecated, and they refer now to the first > linked file and URL from the new file layout rather than the Local- > Url and Url fields. > > Christiaan > > On 13 Jan 2008, at 6:31 PM, Nicholas Cole wrote: > >> Dear All, >> >> Does anyone else find that the new release has broken the "JSTOR >> Download PDF" script from [EMAIL PROTECTED] >> >> If so, does anyone know why? >> >> Best wishes, >> >> Nicholas >> > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] download pdf script broken
I don't know why, but it may be related to the new file layout. This is also reflected in the AppleScript support. E.g. 'local file' and 'remote URL' are now deprecated, and they refer now to the first linked file and URL from the new file layout rather than the Local- Url and Url fields. Christiaan On 13 Jan 2008, at 6:31 PM, Nicholas Cole wrote: > Dear All, > > Does anyone else find that the new release has broken the "JSTOR > Download PDF" script from [EMAIL PROTECTED] > > If so, does anyone know why? > > Best wishes, > > Nicholas > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] download pdf script broken
Dear All, Does anyone else find that the new release has broken the "JSTOR Download PDF" script from [EMAIL PROTECTED] If so, does anyone know why? Best wishes, Nicholas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] CiteInPages 0.98a bug fix
CiteInPages version 0.98a fixes several bugs in the author-date script related to the substitution of editors or title content for authors when authors (or editors) are not specified. CiteInPages is a package of Applescripts and templates for BibDesk that format in-text citations and bibliographies in Apple's Pages v. 3. http://jhh.med.virginia.edu/main/CiteInPages Jim Harrison University of Virginia - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
