You can set up BibDesk so that it files attachments relative to the location of the. The Local-URL field will only find the linked file if it contains either an absolute path (which Eratosthenes has obviously no way of knowing) or if it is a relative path relative to the location of the. However, this has no bearing on how it interprets the Local-URL field (or any field of the "local file" type). the attachment from Eratosthenes should replace the existing local file, one could presumably just delete that field from the entry - however, the user would then need to manually delete the file itself.ģ) BibDesk preferences allow setting a fixed filing location for attachments. If the Local URL should replace the Bdsk-File-X - i.e. The downside here is that the user would need to teach BibDesk for each X in Local-URL-X that the field is of the local file type.Ģ) If the local file count is already >0 (in other words, there is at least one Bdsk-File-X field), BibDesk will add the local link resulting from the conversion process rather than replace any existing link. There is a very good Apple script that I use to populate the Local-URL fields ( ) - it basically reverts the conversion process BibDesk does while keeping the Bdsk-File-X field intact - and if it finds more than one local file, it simply adds a Local-URL-X (with X from 2 to highest attachment count of all entries) field. I tried using spaces, a comma-separated list and a semicolon-separated list no dice. If you specify more than one path, it will not be able to convert it. I played with the Local URL field a bit more:ġ) BibDesk only takes one argument in this field. I envision the first round implementation supporting single file attachments, exporting them to the local-URL field, and importing from this field if it is present (for example if the user has not run the "Database->convert file and url fields" yet). Deciding how to export paths to bibdesk is critical here. bibtex:// is relative to your bibtex file location, library:// is relative to your library location (either bibtex file location or, optionally, another location chosen in the settings), dropbox:// is relative to the dropbox root. bib file location, or can you specify a folder in BibDesk to find your PDFs in?Įratosthenes currently uses special uri protocols to refer to locations. How should the local-URL paths work? Should they be relative to the.How should this behave when there are pre-existing attachments?.How should this behave with multiple attachments?.However, there are a number of edge cases to consider. This sounds like a reasonable way to proceed. This automatically converted the relative path in the Local URL field to a entry in the Bdsk-File-X field, containing the base64 encoded alias to the file. Lastly, I selected "Database-Convert File and URL Fields" from the BibDesk menu (here you can do that either on all entries or just selected entries). I have then added the relative path pointing from the bib file to the PDF to the Local-URL field of the relevant entry. Sources subfolder in the folder where my bib file lives. I chose to name the field Local-URL (I forget why I chose that name originally but that is also the name used in my BibLatex style), but it could be anything.Īfter syncing my library containing the entry back to my Mac, I manually added a PDF to my. Here is how it goes:īibDesk allows the user to set up any arbitrary field to contain a local URL by going to "Preferences-Default Fields", assigning the Local File field a name and selecting "Local File" as type. I have tried it out with an entry (originally created in Erastothenes as a Google Scholar import love that feature!). It is possible to add local files to a BibDesk entry without using the base64 encoded aliases.
0 Comments
Leave a Reply. |