Re: [Bibdesk-users] autofile local-url
(I have not tried out the nightly) On Sep 30, 2007, at 12:42 PM, Christiaan Hofman wrote: > I think that leads to far. You may be recreating a subset of your > whole computer. I would tend to disagree. The advice on this list is for references with multiple PDFs, you should link to a folder. So all these entries are essentially non-transferable. Why not trust how the user has build his library? I would think it better not to second guess him/ her. The only nasty sideeffects would be creating a very large tarball, running out of disk space or wasting cpu cycles. Kasper > Christiaan > > On 30 Sep 2007, at 9:35 PM, Alexander H. Montgomery wrote: > >> Hmm, looks like a good start. A couple of issues: >> >> Names and fields: It currently drops all the PDFs into the same dir >> as the .bib file. It could instead create a folder hierarchy based on >> the common parent of all the PDFs and correct the local-url-type >> fields from there. >> >> Folders:When I had a folder as a local-url-type field, it instead put >> in a zero KB file. >> >> -A >> >> On Sep 30, 2007, at 11:09 AM, Christiaan Hofman wrote: >> >>> >>> On 28 Sep 2007, at 9:18 PM, Adam R. Maxwell wrote: >>> On Friday, September 28, 2007, at 12:15PM, "Alexander H. Montgomery" <[EMAIL PROTECTED]> wrote: > On this topic, I was thinking of putting in a feature request > along > these lines: Having an export option that tarballed (or zipped, or > whatever) selected or all references, along with attached PDFs, in > such a way that someone else could open up the library and have > the > PDF links "just work." > > Thoughts? Endnote (finally) introduced this feature in 10.0. Christiaan added something like this recently. Try Export->BibTeX and Papers Archive (or something like that) in a nightly build. Adam >>> >>> Though it does not correct the local-urls to be relative. >>> >>> Christiaan >>> >>> >>> >>> >>> - >>> - >>> --- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >>> ___ >>> Bibdesk-users mailing list >>> Bibdesk-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users >>> >> >> >> - >> - >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >> ___ >> Bibdesk-users mailing list >> Bibdesk-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] autofile local-url
On 10/1/07, Kasper Daniel Hansen <[EMAIL PROTECTED]> wrote: > > (I have not tried out the nightly) > > On Sep 30, 2007, at 12:42 PM, Christiaan Hofman wrote: > > > I think that leads to far. You may be recreating a subset of your > > whole computer. > > I would tend to disagree. The advice on this list is for references > with multiple PDFs, you should link to a folder. So all these entries > are essentially non-transferable. Why not trust how the user has > build his library? I would think it better not to second guess him/ > her. The only nasty sideeffects would be creating a very large > tarball, running out of disk space or wasting cpu cycles. > > Kasper It's not second guessing, it's guessing. BibDesk does not assume anywhere that linked files are organized in any way, or that AutoFile is turned on. So linked files can be located on vastly different location on the computer, even on different locations on a network. (my remarks are about recreating the folder hierarchy, not about adding PDFs in a linked folder). Christiaan > Christiaan > > > > On 30 Sep 2007, at 9:35 PM, Alexander H. Montgomery wrote: > > > >> Hmm, looks like a good start. A couple of issues: > >> > >> Names and fields: It currently drops all the PDFs into the same dir > >> as the .bib file. It could instead create a folder hierarchy based on > >> the common parent of all the PDFs and correct the local-url-type > >> fields from there. > >> > >> Folders:When I had a folder as a local-url-type field, it instead put > >> in a zero KB file. > >> > >> -A > >> > >> On Sep 30, 2007, at 11:09 AM, Christiaan Hofman wrote: > >> > >>> > >>> On 28 Sep 2007, at 9:18 PM, Adam R. Maxwell wrote: > >>> > > On Friday, September 28, 2007, at 12:15PM, "Alexander H. > Montgomery" <[EMAIL PROTECTED]> wrote: > > On this topic, I was thinking of putting in a feature request > > along > > these lines: Having an export option that tarballed (or zipped, or > > whatever) selected or all references, along with attached PDFs, in > > such a way that someone else could open up the library and have > > the > > PDF links "just work." > > > > Thoughts? Endnote (finally) introduced this feature in 10.0. > > Christiaan added something like this recently. Try Export->BibTeX > and Papers Archive (or something like that) in a nightly build. > > Adam > >>> > >>> Though it does not correct the local-urls to be relative. > >>> > >>> Christiaan > >>> > >>> > >>> > >>> > >>> - > >>> - > >>> --- > >>> This SF.net email is sponsored by: Microsoft > >>> Defy all challenges. Microsoft(R) Visual Studio 2005. > >>> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > >>> ___ > >>> Bibdesk-users mailing list > >>> Bibdesk-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > >>> > >> > >> > >> - > >> - > >> --- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2005. > >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > >> ___ > >> Bibdesk-users mailing list > >> Bibdesk-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > > > > -- > > --- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > ___ > > Bibdesk-users mailing list > > Bibdesk-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] autofile local-url
I think Christiaan was referring to suggestion #1 (recreate hierarchy) rather than #2 (archive folders properly). It seems to me that #2 is necessary. As far as #1 goes, there are two options I can see: A. Recreate hierarchy from common parent. The argument for recreating hierarchy is that it covers all cases well. If someone's scattered PDFs all over their hard drive, this will add a few more layers of folders, but take no more space. If they've put their .bib file in one folder and everything else in a designated Papers folder, it will nicely recreate the hierarchy in the Papers folder. If they use filing relative to the .bib file, then this will nicely recreate that relationship. B. The other option (one or the other has to be done, otherwise the recipient will get a .bib file with a lot of broken PDF links) is to change the local-url field in the archived .bib file to point to the correct target. The problem with this option is if there are two PDFs named the same thing, but in different directories, option A will automatically "do the right thing," whereas option B will require renaming the PDF before archiving. -AHM On Oct 1, 2007, at 10:19 AM, Kasper Daniel Hansen wrote: > (I have not tried out the nightly) > > On Sep 30, 2007, at 12:42 PM, Christiaan Hofman wrote: > >> I think that leads to far. You may be recreating a subset of your >> whole computer. > > I would tend to disagree. The advice on this list is for references > with multiple PDFs, you should link to a folder. So all these entries > are essentially non-transferable. Why not trust how the user has > build his library? I would think it better not to second guess him/ > her. The only nasty sideeffects would be creating a very large > tarball, running out of disk space or wasting cpu cycles. > > Kasper > > >> Christiaan >> >> On 30 Sep 2007, at 9:35 PM, Alexander H. Montgomery wrote: >> >>> Hmm, looks like a good start. A couple of issues: >>> >>> Names and fields: It currently drops all the PDFs into the same dir >>> as the .bib file. It could instead create a folder hierarchy >>> based on >>> the common parent of all the PDFs and correct the local-url-type >>> fields from there. >>> >>> Folders:When I had a folder as a local-url-type field, it instead >>> put >>> in a zero KB file. >>> >>> -A >>> >>> On Sep 30, 2007, at 11:09 AM, Christiaan Hofman wrote: >>> On 28 Sep 2007, at 9:18 PM, Adam R. Maxwell wrote: > > On Friday, September 28, 2007, at 12:15PM, "Alexander H. > Montgomery" <[EMAIL PROTECTED]> wrote: >> On this topic, I was thinking of putting in a feature request >> along >> these lines: Having an export option that tarballed (or >> zipped, or >> whatever) selected or all references, along with attached >> PDFs, in >> such a way that someone else could open up the library and have >> the >> PDF links "just work." >> >> Thoughts? Endnote (finally) introduced this feature in 10.0. > > Christiaan added something like this recently. Try Export->BibTeX > and Papers Archive (or something like that) in a nightly build. > > Adam Though it does not correct the local-urls to be relative. Christiaan --- - - - --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users >>> >>> >>> >>> - >>> - >>> --- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >>> ___ >>> Bibdesk-users mailing list >>> Bibdesk-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users >> >> >> - >> - >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >> ___ >> Bibdesk-users mailing list >> Bibdesk-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > -- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Bibdesk-users mailing list > Bibdesk-users@li
[Bibdesk-users] adding field using applescript
Dear Bibdesk-users. I would like to add a new field to a collection of publications using applescript. Could any of you give me a hint how to do that? I can see from the sample script included with BibDesk how to create new publications, but how do I produce an extra field for existing publications (with some preexisting fields)? Best regards, Karsten. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] autofile local-url
On 1 Oct 2007, at 7:28 PM, Alexander H. Montgomery wrote: > I think Christiaan was referring to suggestion #1 (recreate > hierarchy) rather than #2 (archive folders properly). It seems to me > that #2 is necessary. As far as #1 goes, there are two options I can > see: > > A. Recreate hierarchy from common parent. The argument for recreating > hierarchy is that it covers all cases well. If someone's scattered > PDFs all over their hard drive, this will add a few more layers of > folders, but take no more space. If they've put their .bib file in > one folder and everything else in a designated Papers folder, it will > nicely recreate the hierarchy in the Papers folder. If they use > filing relative to the .bib file, then this will nicely recreate that > relationship. > This would still lead to broken links if the Local-Urls are absolute URLs. And it makes assumptions that the PDFs are not scattered around the network or something. > B. The other option (one or the other has to be done, otherwise the > recipient will get a .bib file with a lot of broken PDF links) is to > change the local-url field in the archived .bib file to point to the > correct target. The problem with this option is if there are two PDFs > named the same thing, but in different directories, option A will > automatically "do the right thing," whereas option B will require > renaming the PDF before archiving. > > -AHM > The way we add the files automatically renames the files in case of naming conflicts. However I cannot think of any way to couple this back to the bibtex, as those things take place in completely separate parts of the code. Moreover when the actual filenames of the included PDFs are determined, they have no link anymore to the items they correspond to. So I don't see how to do that. And I find this far too inessential a feature to add all kinds of fragile special case handling as a workaround. Christiaan > On Oct 1, 2007, at 10:19 AM, Kasper Daniel Hansen wrote: > >> (I have not tried out the nightly) >> >> On Sep 30, 2007, at 12:42 PM, Christiaan Hofman wrote: >> >>> I think that leads to far. You may be recreating a subset of your >>> whole computer. >> >> I would tend to disagree. The advice on this list is for references >> with multiple PDFs, you should link to a folder. So all these entries >> are essentially non-transferable. Why not trust how the user has >> build his library? I would think it better not to second guess him/ >> her. The only nasty sideeffects would be creating a very large >> tarball, running out of disk space or wasting cpu cycles. >> >> Kasper >> >> >>> Christiaan >>> >>> On 30 Sep 2007, at 9:35 PM, Alexander H. Montgomery wrote: >>> Hmm, looks like a good start. A couple of issues: Names and fields: It currently drops all the PDFs into the same dir as the .bib file. It could instead create a folder hierarchy based on the common parent of all the PDFs and correct the local-url-type fields from there. Folders:When I had a folder as a local-url-type field, it instead put in a zero KB file. -A On Sep 30, 2007, at 11:09 AM, Christiaan Hofman wrote: > > On 28 Sep 2007, at 9:18 PM, Adam R. Maxwell wrote: > >> >> On Friday, September 28, 2007, at 12:15PM, "Alexander H. >> Montgomery" <[EMAIL PROTECTED]> wrote: >>> On this topic, I was thinking of putting in a feature request >>> along >>> these lines: Having an export option that tarballed (or >>> zipped, or >>> whatever) selected or all references, along with attached >>> PDFs, in >>> such a way that someone else could open up the library and have >>> the >>> PDF links "just work." >>> >>> Thoughts? Endnote (finally) introduced this feature in 10.0. >> >> Christiaan added something like this recently. Try Export- >> >BibTeX >> and Papers Archive (or something like that) in a nightly build. >> >> Adam > > Though it does not correct the local-urls to be relative. > > Christiaan > > > > -- > - > - > - > - > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Bibdesk-users mailing list > Bibdesk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > --- - - - --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list B
Re: [Bibdesk-users] adding field using applescript
Just set the value of the field, and the field is automatically added. Christiaan On 1 Oct 2007, at 7:51 PM, Karsten W. Jacobsen wrote: > > Dear Bibdesk-users. > > I would like to add a new field to a collection of publications > using applescript. Could any of you give me a hint how to do that? > I can see from the sample script included with BibDesk how to > create new publications, but how do I produce an extra field for > existing publications (with some preexisting fields)? > > Best regards, > Karsten. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Re: [Bibdesk-users] autofile local-url
On Oct 1, 2007, at 11:03 AM, Christiaan Hofman wrote: > > On 1 Oct 2007, at 7:28 PM, Alexander H. Montgomery wrote: > >> B. The other option (one or the other has to be done, otherwise the >> recipient will get a .bib file with a lot of broken PDF links) is to >> change the local-url field in the archived .bib file to point to the >> correct target. The problem with this option is if there are two PDFs >> named the same thing, but in different directories, option A will >> automatically "do the right thing," whereas option B will require >> renaming the PDF before archiving. >> >> -AHM >> > > The way we add the files automatically renames the files in case of > naming conflicts. However I cannot think of any way to couple this > back to the bibtex, as those things take place in completely separate > parts of the code. Moreover when the actual filenames of the included > PDFs are determined, they have no link anymore to the items they > correspond to. So I don't see how to do that. And I find this far too > inessential a feature to add all kinds of fragile special case > handling as a workaround. > > Christiaan Hmm, OK, I didn't know that these were completely separate parts of the code. This could probably be done through AppleScript by the user if desired. -AHM - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
[Bibdesk-users] BibDesk: Problem with 'compiling' references
Hello Everybody, I'm new to TeX, so please don't judge me for a potentially trivial question. I'm using BibDesk and have a problem with exporting references. I have a number of "proceedings" items in my library that are cross-referenced by "inproceedings" papers. Whenever I try to "Preview" or "Copy Drag" improceeddings items it results in 2(two) references instead of one. Since my BibDesk version is up to date and the BibTeX version as well, I'd expect it to handle crossref field correctly. I've set the appropriate sorting of the items (proceedings after inproceedings). I've tried exporting properly formatted references both to RTF and PDF Nothing seems to work. Any help is appreciated. Best, Michael -- Michael V. Yudelson, PhD candidate School of Information Science, University of Pittsburgh. Email: [EMAIL PROTECTED] Tel: +1 (412) 624-9437 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
