[email protected] wrote:
>Send Bibdesk-users mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/bibdesk-users >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Bibdesk-users digest..." > >Today's Topics: > > 1. Re: Bibliographic Database (Adam R. Maxwell) > 2. Re: Bibliographic Database (Fischlin Andreas) > 3. Re: Bibliographic Database (Adam R. Maxwell) > 4. pdf importing and filing question (Josef Trapani) > 5. Re: pdf importing and filing question (Christiaan Hofman) > 6. Re: pdf importing and filing question (Jason Davies) > 7. Re: pdf importing and filing question (Josef Trapani) > > >On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote: > >> My personal data base has 13'591 records and I do not know how sluggish BD >> would get if I would transfer all records to it. > >File a bug with a sample if it's slow. The largest file I tested with has >~25000 entries, and the only slowdowns I recall were in searching (fixed) and >smart groups (which you can now hide in the source list). > > > > > >On 08/Jan/2010, at 16:19 , Adam R. Maxwell wrote: > >> >> On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote: >> >>> My personal data base has 13'591 records and I do not know how >>> sluggish BD would get if I would transfer all records to it. >> >> File a bug with a sample if it's slow. The largest file I tested >> with has ~25000 entries, and the only slowdowns I recall were in >> searching (fixed) and smart groups (which you can now hide in the >> source list). > >Good to know. Also all with abstracts? I just didn't dare to test it. >Will do some times in the future when I have some minutes to spare. > >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast >> and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Bibdesk-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > > > >On Jan 9, 2010, at 8:05 AM, Fischlin Andreas wrote: > >> On 08/Jan/2010, at 16:19 , Adam R. Maxwell wrote: >> >>> On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote: >>> >>>> My personal data base has 13'591 records and I do not know how >>>> sluggish BD would get if I would transfer all records to it. >>> >>> File a bug with a sample if it's slow. The largest file I tested >>> with has ~25000 entries, and the only slowdowns I recall were in >>> searching (fixed) and smart groups (which you can now hide in the >>> source list). >> >> Good to know. Also all with abstracts? > >I don't know. It's also been a couple of years since I did that profiling, >and lots of things have changed. > >> I just didn't dare to test it. >> Will do some times in the future when I have some minutes to spare. > >You can only find problems by testing, but here are my guesses: having >abstracts in all of them would increase the memory footprint, and make >searching by "any field" somewhat slower. If you have sufficient RAM and >multiple cores, you won't notice that. Smart groups that depend on abstract >would likely be slow. > > > > > >Greetings, > >I am currently managing my PDF files by auto filing them in a specific folder >and naming them by the associated reference's Pmid (Pubmed ID). >In order to fulfill the Auto File Local File Format rules my format string is: >%f{Pmid}0%n[_]0.pdf >With the %n[_]0 I end up with duplicates of the same pdf if I accidentally >drag the same pdf into bibdesk a second (or third) time. >This often happens because my Auto File folder has 2,600 pdf files in it. > >I have three questions: > >1) Is there a way for Import Publications to scan my reference library to >determine if I have already have a reference for the incoming pdf? Currently, >when I download a pdf that I think I don't have (but actually do) and drag it >onto my large primary .bib file I end up with a duplicate pdf file with _0 >added to the filename (as per my format string). > >2) Is there a way to make Import Publications scan my Auto File folder to >determine if the pdf that I am importing already exists? Currently, if I am >working with a smaller .bib reference list dragging in a given pdf is very >useful to populate that reference into my .bib file, but if I already have the >pdf then I don't necessarily need another copy in my Auto File Folder. This >can occur when someone has emailed me a pdf and I want to import it into a >unique .bib file. > >It seems that 1) and 2) could be accomplished in the same task, first scanning >whether or not the incoming pdf's associated reference exists, and adding it >if it doesn't, and then determining if the pdf already exists and adding it if >it doesn't. > >3) Is there a way to scan all existing references in a .bib file and >auto-associate pdf's from the Auto File Folder to references with matching >Pmid's (or other unique identifier)? This happens when I create a new bib file >with new references and I already have pdf's in my Auto File Folder. This is >different from question 2) because here the reference already exists in the >file and the pdf may already exist in the folder. > >I have a script hook to compare an incoming pdf filename with all pdf file >names in my Auto File Folder, however the Import Publications feature >overrides any attempt at stopping a pdf's auto filing or a reference's >creation. > >Many thanks for any and all advice, >Joe > > > > > > > >On Jan 12, 2010, at 1:51, Josef Trapani wrote: > >> Greetings, >> >> I am currently managing my PDF files by auto filing them in a specific >> folder and naming them by the associated reference's Pmid (Pubmed ID). >> In order to fulfill the Auto File Local File Format rules my format string >> is: %f{Pmid}0%n[_]0.pdf >> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally >> drag the same pdf into bibdesk a second (or third) time. >> This often happens because my Auto File folder has 2,600 pdf files in it. >> >> I have three questions: >> >> 1) Is there a way for Import Publications to scan my reference library to >> determine if I have already have a reference for the incoming pdf? >> Currently, when I download a pdf that I think I don't have (but actually do) >> and drag it onto my large primary .bib file I end up with a duplicate pdf >> file with _0 added to the filename (as per my format string). > >Most definitely not. Especially when you're talking about "duplicate" rather >than "identical" files (which I think you are.) > >> >> 2) Is there a way to make Import Publications scan my Auto File folder to >> determine if the pdf that I am importing already exists? Currently, if I am >> working with a smaller .bib reference list dragging in a given pdf is very >> useful to populate that reference into my .bib file, but if I already have >> the pdf then I don't necessarily need another copy in my Auto File Folder. >> This can occur when someone has emailed me a pdf and I want to import it >> into a unique .bib file. >> > >Same answer. > >> It seems that 1) and 2) could be accomplished in the same task, first >> scanning whether or not the incoming pdf's associated reference exists, and >> adding it if it doesn't, and then determining if the pdf already exists and >> adding it if it doesn't. >> > >Except that it would be extremely and prohibitively inefficient, so we can't >do that. > >> 3) Is there a way to scan all existing references in a .bib file and >> auto-associate pdf's from the Auto File Folder to references with matching >> Pmid's (or other unique identifier)? This happens when I create a new bib >> file with new references and I already have pdf's in my Auto File Folder. >> This is different from question 2) because here the reference already exists >> in the file and the pdf may already exist in the folder. >> > >Not for PMID. There is a way to try to match pubs and (unattached) files based >on author names using the Match Files feature. > >> I have a script hook to compare an incoming pdf filename with all pdf file >> names in my Auto File Folder, however the Import Publications feature >> overrides any attempt at stopping a pdf's auto filing or a reference's >> creation. >> >> Many thanks for any and all advice, >> Joe >> > >When you're using auto-filing, comparing file names is completely useless. > >Christiaan > > > >On 12 Jan 2010, at 01:15, Christiaan Hofman wrote: > >>> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally >>> drag the same pdf into bibdesk a second (or third) time. >>> This often happens because my Auto File folder has 2,600 pdf files in it. > >sounds like a folder action might work if you can get the syntax of searching >for a file. I don't know if a folder action could interrupt BibDesk's >operation but it could give you a dialog box alerting you. or (more basic) >reveal the new file in the Finder so you can see for yourself (ie every time >you drop a file on BD, it would show you the resulting file. That would be a >mix of efficiency (no real work for the CPU) and what you need? > > >Thanks Jason, > >Here's the folder script I attached to my Autofile Folder: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >property dialog_timeout : 30 -- set the amount of time before dialogs >auto-answer. >on adding folder items to this_folder after receiving added_item > try > --generate list of PDF files in Auto File folder > tell application "Finder" > set Alist to name of every file of folder this_folder as text > end tell > set thePath to POSIX path of added_item > set AppleScript's text item delimiters to "/" > set thefilename to text item -1 of thePath > --assuming auto file file format adds an underscore (_01) when > duplicating a pdf > set AppleScript's text item delimiters to "_" > set theshortfilename to (text item -1 of thefilename) as text > if theshortfilename is in Alist then > set the alert_message to "This PDF exists, would you like to > see the copy?" > display dialog the alert_message buttons {"Yes", "No"} default > button 2 with icon 1 giving up after dialog_timeout > set the user_choice to the button returned of the result > if user_choice is "Yes" then > tell application "Finder" > activate > open this_folder > reveal the added_item > end tell > end if > end if > end try >end adding folder items to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > >On Jan 11, 2010, at 5:34 PM, Jason Davies wrote: > >> >> On 12 Jan 2010, at 01:15, Christiaan Hofman wrote: >> >>>> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally >>>> drag the same pdf into bibdesk a second (or third) time. >>>> This often happens because my Auto File folder has 2,600 pdf files in it. >> >> sounds like a folder action might work if you can get the syntax of >> searching for a file. I don't know if a folder action could interrupt >> BibDesk's operation but it could give you a dialog box alerting you. or >> (more basic) reveal the new file in the Finder so you can see for yourself >> (ie every time you drop a file on BD, it would show you the resulting file. >> That would be a mix of efficiency (no real work for the CPU) and what you >> need? >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Bibdesk-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > >------------------------------------------------------------------------------ >This SF.Net email is sponsored by the Verizon Developer Community >Take advantage of Verizon's best-in-class app development support >A streamlined, 14 day to market process makes app distribution fast and easy >Join now and get one step closer to millions of Verizon customers >http://p.sf.net/sfu/verizon-dev2dev >_______________________________________________ >Bibdesk-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/bibdesk-users ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
