[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
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
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
[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] 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
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 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 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: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: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 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 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, 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 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
[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] 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
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 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
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
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
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
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] 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] 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] 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] 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] 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
