You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
(4) |
May
(14) |
Jun
(12) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(5) |
Nov
(21) |
Dec
(7) |
2004 |
Jan
(13) |
Feb
(5) |
Mar
(37) |
Apr
(17) |
May
(5) |
Jun
(18) |
Jul
(19) |
Aug
(16) |
Sep
(63) |
Oct
(108) |
Nov
(65) |
Dec
(132) |
2005 |
Jan
(73) |
Feb
(176) |
Mar
(131) |
Apr
(106) |
May
(153) |
Jun
(99) |
Jul
(94) |
Aug
(110) |
Sep
(218) |
Oct
(194) |
Nov
(257) |
Dec
(200) |
2006 |
Jan
(178) |
Feb
(182) |
Mar
(152) |
Apr
(58) |
May
(135) |
Jun
(113) |
Jul
(103) |
Aug
(197) |
Sep
(101) |
Oct
(101) |
Nov
(68) |
Dec
(208) |
2007 |
Jan
(520) |
Feb
(203) |
Mar
(197) |
Apr
(200) |
May
(110) |
Jun
(167) |
Jul
(162) |
Aug
(206) |
Sep
(199) |
Oct
(312) |
Nov
(283) |
Dec
(246) |
2008 |
Jan
(350) |
Feb
(163) |
Mar
(233) |
Apr
(168) |
May
(183) |
Jun
(152) |
Jul
(130) |
Aug
(81) |
Sep
(79) |
Oct
(158) |
Nov
(98) |
Dec
(153) |
2009 |
Jan
(230) |
Feb
(171) |
Mar
(108) |
Apr
(68) |
May
(140) |
Jun
(53) |
Jul
(52) |
Aug
(110) |
Sep
(68) |
Oct
(17) |
Nov
(28) |
Dec
(82) |
2010 |
Jan
(141) |
Feb
(80) |
Mar
(39) |
Apr
(102) |
May
(86) |
Jun
(37) |
Jul
(56) |
Aug
(62) |
Sep
(108) |
Oct
(24) |
Nov
(7) |
Dec
(27) |
2011 |
Jan
(19) |
Feb
(18) |
Mar
(33) |
Apr
(45) |
May
(38) |
Jun
(53) |
Jul
(26) |
Aug
(142) |
Sep
(78) |
Oct
(75) |
Nov
(79) |
Dec
(19) |
2012 |
Jan
(49) |
Feb
(39) |
Mar
(28) |
Apr
(14) |
May
(56) |
Jun
(16) |
Jul
(41) |
Aug
(17) |
Sep
(15) |
Oct
(38) |
Nov
(35) |
Dec
(22) |
2013 |
Jan
(44) |
Feb
(30) |
Mar
(30) |
Apr
(53) |
May
(1) |
Jun
(4) |
Jul
(9) |
Aug
(21) |
Sep
(22) |
Oct
(2) |
Nov
(26) |
Dec
(58) |
2014 |
Jan
(27) |
Feb
(2) |
Mar
(2) |
Apr
(19) |
May
(11) |
Jun
(10) |
Jul
(7) |
Aug
(15) |
Sep
(42) |
Oct
(50) |
Nov
(45) |
Dec
(18) |
2015 |
Jan
(18) |
Feb
(9) |
Mar
(30) |
Apr
(17) |
May
(28) |
Jun
(4) |
Jul
(6) |
Aug
(5) |
Sep
|
Oct
(32) |
Nov
(29) |
Dec
(9) |
2016 |
Jan
(14) |
Feb
(16) |
Mar
(7) |
Apr
(5) |
May
(2) |
Jun
(13) |
Jul
(4) |
Aug
(10) |
Sep
(7) |
Oct
(14) |
Nov
(2) |
Dec
(11) |
2017 |
Jan
(1) |
Feb
(10) |
Mar
(14) |
Apr
(3) |
May
(8) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(10) |
Oct
(13) |
Nov
(4) |
Dec
(10) |
2018 |
Jan
(3) |
Feb
(9) |
Mar
(12) |
Apr
(17) |
May
(23) |
Jun
(12) |
Jul
(58) |
Aug
(3) |
Sep
(46) |
Oct
(3) |
Nov
(11) |
Dec
(53) |
2019 |
Jan
(14) |
Feb
(38) |
Mar
(2) |
Apr
(12) |
May
(20) |
Jun
(8) |
Jul
(7) |
Aug
(2) |
Sep
|
Oct
(21) |
Nov
|
Dec
(19) |
2020 |
Jan
(7) |
Feb
(3) |
Mar
(27) |
Apr
(23) |
May
(7) |
Jun
(16) |
Jul
(25) |
Aug
(10) |
Sep
(7) |
Oct
(11) |
Nov
(19) |
Dec
(27) |
2021 |
Jan
(5) |
Feb
(22) |
Mar
(16) |
Apr
(4) |
May
(15) |
Jun
(2) |
Jul
(7) |
Aug
(3) |
Sep
(55) |
Oct
(34) |
Nov
(10) |
Dec
(1) |
2022 |
Jan
|
Feb
(6) |
Mar
(36) |
Apr
(4) |
May
(6) |
Jun
(18) |
Jul
|
Aug
(3) |
Sep
(16) |
Oct
(1) |
Nov
|
Dec
|
2023 |
Jan
(7) |
Feb
(8) |
Mar
(15) |
Apr
(7) |
May
(23) |
Jun
(14) |
Jul
(9) |
Aug
(2) |
Sep
(10) |
Oct
(7) |
Nov
(2) |
Dec
|
2024 |
Jan
(15) |
Feb
(30) |
Mar
(4) |
Apr
(18) |
May
(25) |
Jun
(7) |
Jul
(7) |
Aug
(2) |
Sep
(21) |
Oct
(13) |
Nov
|
Dec
|
2025 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(8) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
From: Trevor J. <bsl...@gm...> - 2025-10-02 16:49:53
|
On 2 Oct 2025, at 15:05, Christiaan Hofman <cmh...@gm...> wrote: > >> On 2 Oct 2025, at 12:13, Trevor Jenkins <bsl...@gm... <mailto:bsl...@gm...>> wrote: >> >> I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references? > > > You may also have to change the text encoding in the TeX Preview preferences.Usually UTF-8 works best. Already have it set to UTF-8 for preview; been so since I first started with BibDesk. Turns out the TeX template encoding setting was (part of) the culprit. Changing that to UTF-8 as well fixed the problem. 감사합니다. Thank you! Regards, Trevor. <>< Re: deemed! |
From: Christiaan H. <cmh...@gm...> - 2025-10-02 14:06:05
|
> On 2 Oct 2025, at 12:13, Trevor Jenkins <bsl...@gm...> wrote: > > I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references? > > Environment > MacTex 2023 (plan to upgrade to 2025 version ASAP) > macOS 15.6 Sequoia (holding off on upgrade to Taheo because of report problems) > BibDesk 1.9.7 > > Regards, Trevor. > > <>< Re: deemed! You may also have to change the text encoding in the TeX Preview preferences.Usually UTF-8 works best. Christiaan |
From: Trevor J. <bsl...@gm...> - 2025-10-02 10:13:59
|
I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references? Environment MacTex 2023 (plan to upgrade to 2025 version ASAP) macOS 15.6 Sequoia (holding off on upgrade to Taheo because of report problems) BibDesk 1.9.7 Regards, Trevor. <>< Re: deemed! |
From: Fischlin A. <and...@en...> - 2025-06-08 14:50:45
|
Dear Alan, I see no reason why one should change well established syntax rules of BibTeX. Sharing with others is exactly the reason why one should stick to the rules and conventions. I appreciate that BibDesk is enforcing those rules and conventions precisely for those reasons. The fact that many programmers responsible for citation exports from many journals are ignorant of those rules is also no reason to arbitrarily change those rules, e.g. in BibDesk. They simply have to learn. I regularly find myself reminding journals repeatedly of those rules, sic. To use throughout in all TeX, LaTeX, BibTeX etc. UTF-8 would be a major revision with far reaching consequences requiring huge programming efforts I would rather not recommend. Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin Formerly IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en... <mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.html <http://www.sysecol.ethz.ch/people/andreas.fischlin.html> +41 44 633-6090 phone +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ > On 7 Jun 2025, at 17:46, Adam R. Maxwell via Bibdesk-users <bib...@li...> wrote: > > >> On Jun 7, 2025, at 08:18 , Alan Munn via Bibdesk-users <bib...@li... <mailto:bib...@li...>> wrote: >> >> It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported. > > Technically a BibTeX citekey is a LaTeX command, so restricted to the same set of characters. The restriction is relaxed quite a bit to include things like dashes, but it doesn't extend to accented characters. I can imagine UTF-8 might pass through biber or bibtex, but you're playing with fire. > > This looks like a pretty good answer. BibDesk basically assumes you're using LaTeX (and IIRC the btparse library enforces this): > > https://tex.stackexchange.com/questions/581901/what-is-the-safe-character-set-for-a-bibtex-label# > > Adam > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users |
From: Adam R. M. <ama...@ma...> - 2025-06-07 17:04:01
|
> On Jun 7, 2025, at 08:18 , Alan Munn via Bibdesk-users <bib...@li...> wrote: > > It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported. Technically a BibTeX citekey is a LaTeX command, so restricted to the same set of characters. The restriction is relaxed quite a bit to include things like dashes, but it doesn't extend to accented characters. I can imagine UTF-8 might pass through biber or bibtex, but you're playing with fire. This looks like a pretty good answer. BibDesk basically assumes you're using LaTeX (and IIRC the btparse library enforces this): https://tex.stackexchange.com/questions/581901/what-is-the-safe-character-set-for-a-bibtex-label# Adam |
From: Christiaan H. <cmh...@gm...> - 2025-06-07 15:35:31
|
That is not correct, BibTeX and biber only allow a restricted set of ASCII characters in the cite key. Christiaan > On 7 Jun 2025, at 17:18, Alan Munn via Bibdesk-users <bib...@li...> wrote: > > It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported. > > Thanks > Alan > > -- > Alan Munn > am...@gm... |
From: Alan M. <am...@gm...> - 2025-06-07 15:32:00
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported.</div> <div> </div> <div>Thanks</div> <div>Alan<br/> </div> <div class="signature">--<br/> Alan Munn<br/> am...@gm...</div></div></body></html> |
From: Nathan <nat...@gm...> - 2025-05-20 12:52:42
|
Jason: As is mentioned in the FAQ in the BibDesk wiki, there are some open-source programs that can decode Bdsk-File-* fields. I mention them in case you didn't know and wanted to look at their code. The Python script bibdesk2zotero by Ed Summers makes use of some Python libraries: https://github.com/edsu/bibdesk2zotero <https://github.com/edsu/bibdesk2zotero> The Better BibTeX for Zotero plugin implemented Bdsk-File-* decoding in response to this issue: https://github.com/retorquere/zotero-better-bibtex/issues/2374 <https://github.com/retorquere/zotero-better-bibtex/issues/2374> And its TypeScript code can be seen in this commit: https://github.com/retorquere/zotero-better-bibtex/commit/dfb04822c01c31845c24ab07ccffa25e4212ac3a <https://github.com/retorquere/zotero-better-bibtex/commit/dfb04822c01c31845c24ab07ccffa25e4212ac3a> Nathan > On May 15, 2025, at 3:21 PM, Alexander,J <ja...@ls...> wrote: > > Ah, yes - you’re right. I had been making that assumption. > > Given these considerations, I think I’ll just stick with my current method that accidentally works, and file these helpful notes away for the time when it no longer works and I need to find a better solution. > > Thank you! > > Jason > > Sent from my iPhone > >> On 15 May 2025, at 17:47, Christiaan Hofman <cmh...@gm...> wrote: >> That makes no sense. I think you are thinking about an alias file. But I am talking about alias data. There is no method to open a file from alias data (except by using system framework methods). >> >> Christiaan >> >>> On 15 May 2025, at 16:47, Alexander,J <ja...@ls...> wrote: >>> >>> If the bookmark is an alias, isn't it possible to open the file directly via the alias, without needing to recover/construct the path? That might not be possible, though, with the functions available in emacs. >>> >>>> On 15 May 2025, at 15:37, Christiaan Hofman <cmh...@gm...> wrote: >>>> There is no documentation of this format. It is basically private.I can give you some partial information. Basically, it is base64 encoded plist data. The plist is a dictionary with 2 keys: relativePath and bookmark. The relativePath gives the path relative to the .bib file. The bookmark is alias data generated by Apple, and its format is not documented. So when you get the(full) path (from this alias data), that is largely by accident. The only robust way to get the (full) path is by resolving the alias using the system Foundation framework (i.e. using an Objective-C or Swift program). Perhaps the best is to get the relative path, and also pass the .bib file path to your function. >>>> For instance, you could get the plist data from the command line using: >>>> echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - >>>> And you can get the relative path using: >>>> echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect string -o - - >>>> Christiaan >>>>> On 15 May 2025, at 11:48, Alexander,J <ja...@ls...> wrote: >>>>> Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? >>>>> I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. >>>>> Many thanks, >>>>> Jason >>>>> (defun open-bibdesk-file () >>>>> "Extract the bdsk-file-1 field and open the file." >>>>> (interactive) >>>>> (save-window-excursion >>>>> ;; Use existing reftex function to locate the entry >>>>> (reftex-view-crossref 2) >>>>> ;; Now we're in the bib file at the entry >>>>> (let (citation-key field-content) >>>>> ;; Find the citation key >>>>> (save-excursion >>>>> (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) >>>>> (setq citation-key (match-string 1)))) >>>>> ;; Find the bdsk-file-1 field in the current entry >>>>> (save-excursion >>>>> (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) >>>>> (progn >>>>> (let* >>>>> ((Bdsk-File-1 (match-string 1)) >>>>> (fstr (base64-decode-string Bdsk-File-1)) >>>>> (info-buffer (get-buffer-create "*Bibdesk Info*")) >>>>> path) >>>>> (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) >>>>> (setq path (format "/%s" (match-string 0 fstr))) >>>>> (with-current-buffer info-buffer >>>>> (erase-buffer) >>>>> (insert (format "path: %s" path)) >>>>> (insert (format "\n\n%s" fstr))) >>>>> (if (and path (file-exists-p path)) >>>>> (shell-command (concat "open " (shell-quote-argument path))) >>>>> (message "File not found"))))))))) |
From: Alexander,J <ja...@ls...> - 2025-05-15 19:21:38
|
Ah, yes - you’re right. I had been making that assumption. Given these considerations, I think I’ll just stick with my current method that accidentally works, and file these helpful notes away for the time when it no longer works and I need to find a better solution. Thank you! Jason Sent from my iPhone > On 15 May 2025, at 17:47, Christiaan Hofman <cmh...@gm...> wrote: > That makes no sense. I think you are thinking about an alias file. But I am talking about alias data. There is no method to open a file from alias data (except by using system framework methods). > > Christiaan > >> On 15 May 2025, at 16:47, Alexander,J <ja...@ls...> wrote: >> >> If the bookmark is an alias, isn't it possible to open the file directly via the alias, without needing to recover/construct the path? That might not be possible, though, with the functions available in emacs. >> >>> On 15 May 2025, at 15:37, Christiaan Hofman <cmh...@gm...> wrote: >>> There is no documentation of this format. It is basically private.I can give you some partial information. Basically, it is base64 encoded plist data. The plist is a dictionary with 2 keys: relativePath and bookmark. The relativePath gives the path relative to the .bib file. The bookmark is alias data generated by Apple, and its format is not documented. So when you get the(full) path (from this alias data), that is largely by accident. The only robust way to get the (full) path is by resolving the alias using the system Foundation framework (i.e. using an Objective-C or Swift program). Perhaps the best is to get the relative path, and also pass the .bib file path to your function. >>> For instance, you could get the plist data from the command line using: >>> echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - >>> And you can get the relative path using: >>> echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect string -o - - >>> Christiaan >>>> On 15 May 2025, at 11:48, Alexander,J <ja...@ls...> wrote: >>>> Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? >>>> I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. >>>> Many thanks, >>>> Jason >>>> (defun open-bibdesk-file () >>>> "Extract the bdsk-file-1 field and open the file." >>>> (interactive) >>>> (save-window-excursion >>>> ;; Use existing reftex function to locate the entry >>>> (reftex-view-crossref 2) >>>> ;; Now we're in the bib file at the entry >>>> (let (citation-key field-content) >>>> ;; Find the citation key >>>> (save-excursion >>>> (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) >>>> (setq citation-key (match-string 1)))) >>>> ;; Find the bdsk-file-1 field in the current entry >>>> (save-excursion >>>> (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) >>>> (progn >>>> (let* >>>> ((Bdsk-File-1 (match-string 1)) >>>> (fstr (base64-decode-string Bdsk-File-1)) >>>> (info-buffer (get-buffer-create "*Bibdesk Info*")) >>>> path) >>>> (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) >>>> (setq path (format "/%s" (match-string 0 fstr))) >>>> (with-current-buffer info-buffer >>>> (erase-buffer) >>>> (insert (format "path: %s" path)) >>>> (insert (format "\n\n%s" fstr))) >>>> (if (and path (file-exists-p path)) >>>> (shell-command (concat "open " (shell-quote-argument path))) >>>> (message "File not found"))))))))) > > > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users |
From: Christiaan H. <cmh...@gm...> - 2025-05-15 16:47:12
|
That makes no sense. I think you are thinking about an alias file. But I am talking about alias data. There is no method to open a file from alias data (except by using system framework methods). Christiaan > On 15 May 2025, at 16:47, Alexander,J <ja...@ls...> wrote: > > If the bookmark is an alias, isn't it possible to open the file directly via the alias, without needing to recover/construct the path? That might not be possible, though, with the functions available in emacs. > >> On 15 May 2025, at 15:37, Christiaan Hofman <cmh...@gm...> wrote: >> >> There is no documentation of this format. It is basically private.I can give you some partial information. Basically, it is base64 encoded plist data. The plist is a dictionary with 2 keys: relativePath and bookmark. The relativePath gives the path relative to the .bib file. The bookmark is alias data generated by Apple, and its format is not documented. So when you get the(full) path (from this alias data), that is largely by accident. The only robust way to get the (full) path is by resolving the alias using the system Foundation framework (i.e. using an Objective-C or Swift program). Perhaps the best is to get the relative path, and also pass the .bib file path to your function. >> >> For instance, you could get the plist data from the command line using: >> >> echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - >> >> And you can get the relative path using: >> >> echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect string -o - - >> >> Christiaan >> >>> On 15 May 2025, at 11:48, Alexander,J <ja...@ls...> wrote: >>> >>> Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? >>> >>> I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. >>> >>> Many thanks, >>> >>> Jason >>> >>> >>> (defun open-bibdesk-file () >>> "Extract the bdsk-file-1 field and open the file." >>> (interactive) >>> (save-window-excursion >>> ;; Use existing reftex function to locate the entry >>> (reftex-view-crossref 2) >>> >>> ;; Now we're in the bib file at the entry >>> (let (citation-key field-content) >>> ;; Find the citation key >>> (save-excursion >>> (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) >>> (setq citation-key (match-string 1)))) >>> >>> ;; Find the bdsk-file-1 field in the current entry >>> (save-excursion >>> (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) >>> (progn >>> (let* >>> ((Bdsk-File-1 (match-string 1)) >>> (fstr (base64-decode-string Bdsk-File-1)) >>> (info-buffer (get-buffer-create "*Bibdesk Info*")) >>> path) >>> (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) >>> (setq path (format "/%s" (match-string 0 fstr))) >>> (with-current-buffer info-buffer >>> (erase-buffer) >>> (insert (format "path: %s" path)) >>> (insert (format "\n\n%s" fstr))) >>> (if (and path (file-exists-p path)) >>> (shell-command (concat "open " (shell-quote-argument path))) >>> (message "File not found"))))))))) |
From: Alexander,J <ja...@ls...> - 2025-05-15 16:20:07
|
If the bookmark is an alias, isn't it possible to open the file directly via the alias, without needing to recover/construct the path? That might not be possible, though, with the functions available in emacs. > On 15 May 2025, at 15:37, Christiaan Hofman <cmh...@gm...> wrote: > > There is no documentation of this format. It is basically private.I can give you some partial information. Basically, it is base64 encoded plist data. The plist is a dictionary with 2 keys: relativePath and bookmark. The relativePath gives the path relative to the .bib file. The bookmark is alias data generated by Apple, and its format is not documented. So when you get the(full) path (from this alias data), that is largely by accident. The only robust way to get the (full) path is by resolving the alias using the system Foundation framework (i.e. using an Objective-C or Swift program). Perhaps the best is to get the relative path, and also pass the .bib file path to your function. > > For instance, you could get the plist data from the command line using: > > echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - > > And you can get the relative path using: > > echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect string -o - - > > Christiaan > >> On 15 May 2025, at 11:48, Alexander,J <ja...@ls...> wrote: >> >> Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? >> >> I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. >> >> Many thanks, >> >> Jason >> >> >> (defun open-bibdesk-file () >> "Extract the bdsk-file-1 field and open the file." >> (interactive) >> (save-window-excursion >> ;; Use existing reftex function to locate the entry >> (reftex-view-crossref 2) >> >> ;; Now we're in the bib file at the entry >> (let (citation-key field-content) >> ;; Find the citation key >> (save-excursion >> (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) >> (setq citation-key (match-string 1)))) >> >> ;; Find the bdsk-file-1 field in the current entry >> (save-excursion >> (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) >> (progn >> (let* >> ((Bdsk-File-1 (match-string 1)) >> (fstr (base64-decode-string Bdsk-File-1)) >> (info-buffer (get-buffer-create "*Bibdesk Info*")) >> path) >> (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) >> (setq path (format "/%s" (match-string 0 fstr))) >> (with-current-buffer info-buffer >> (erase-buffer) >> (insert (format "path: %s" path)) >> (insert (format "\n\n%s" fstr))) >> (if (and path (file-exists-p path)) >> (shell-command (concat "open " (shell-quote-argument path))) >> (message "File not found"))))))))) > > > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users |
From: Christiaan H. <cmh...@gm...> - 2025-05-15 14:37:34
|
There is no documentation of this format. It is basically private.I can give you some partial information. Basically, it is base64 encoded plist data. The plist is a dictionary with 2 keys: relativePath and bookmark. The relativePath gives the path relative to the .bib file. The bookmark is alias data generated by Apple, and its format is not documented. So when you get the(full) path (from this alias data), that is largely by accident. The only robust way to get the (full) path is by resolving the alias using the system Foundation framework (i.e. using an Objective-C or Swift program). Perhaps the best is to get the relative path, and also pass the .bib file path to your function. For instance, you could get the plist data from the command line using: echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - And you can get the relative path using: echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect string -o - - Christiaan > On 15 May 2025, at 11:48, Alexander,J <ja...@ls...> wrote: > > Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? > > I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. > > Many thanks, > > Jason > > > (defun open-bibdesk-file () > "Extract the bdsk-file-1 field and open the file." > (interactive) > (save-window-excursion > ;; Use existing reftex function to locate the entry > (reftex-view-crossref 2) > > ;; Now we're in the bib file at the entry > (let (citation-key field-content) > ;; Find the citation key > (save-excursion > (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) > (setq citation-key (match-string 1)))) > > ;; Find the bdsk-file-1 field in the current entry > (save-excursion > (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) > (progn > (let* > ((Bdsk-File-1 (match-string 1)) > (fstr (base64-decode-string Bdsk-File-1)) > (info-buffer (get-buffer-create "*Bibdesk Info*")) > path) > (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) > (setq path (format "/%s" (match-string 0 fstr))) > (with-current-buffer info-buffer > (erase-buffer) > (insert (format "path: %s" path)) > (insert (format "\n\n%s" fstr))) > (if (and path (file-exists-p path)) > (shell-command (concat "open " (shell-quote-argument path))) > (message "File not found"))))))))) |
From: Alexander,J <ja...@ls...> - 2025-05-15 11:22:09
|
Is there documentation describing how to decode the values of the Bdsk-File-* fields, and extract the path to the file? I ask because I've written the following Emacs macro which, when invoked while the cursor is sitting on a citation key, attempts to open the first such file (if it exists) associated with that entry. At the moment, this seems to work, but when I inspect the results of the Base64 decoding (by visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer and the file path appears in all lower-case... which makes me worry that this macro is working largely by accident and there is a more robust way of doing this. Many thanks, Jason (defun open-bibdesk-file () "Extract the bdsk-file-1 field and open the file." (interactive) (save-window-excursion ;; Use existing reftex function to locate the entry (reftex-view-crossref 2) ;; Now we're in the bib file at the entry (let (citation-key field-content) ;; Find the citation key (save-excursion (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) (setq citation-key (match-string 1)))) ;; Find the bdsk-file-1 field in the current entry (save-excursion (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) (progn (let* ((Bdsk-File-1 (match-string 1)) (fstr (base64-decode-string Bdsk-File-1)) (info-buffer (get-buffer-create "*Bibdesk Info*")) path) (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) (setq path (format "/%s" (match-string 0 fstr))) (with-current-buffer info-buffer (erase-buffer) (insert (format "path: %s" path)) (insert (format "\n\n%s" fstr))) (if (and path (file-exists-p path)) (shell-command (concat "open " (shell-quote-argument path))) (message "File not found"))))))))) |
From: Fischlin A. <and...@en...> - 2025-05-06 10:56:04
|
Dear Christiaan, So far works very well. Thanks to you and all who contributed!!!!! Kindest Regards, Andreas Fischlin ETH Zurich Prof. em. Dr. Andreas Fischlin Formerly IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en... <mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.html <http://www.sysecol.ethz.ch/people/andreas.fischlin.html> +41 44 633-6090 phone +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ > On 6 May 2025, at 10:49, Christiaan Hofman <cmh...@gm...> wrote: > > The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.7, is now available. > > We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. > > This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at > > https://sourceforge.net/projects/bibdesk/ > > or by visiting the BibDesk home page at > > https://bibdesk.sourceforge.io/ > > or by following the link below, which will begin immediate download: > > https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download > > For those interested follow the full release notes for this version. > > Release notes for BibDesk version 1.9.7 > > New Features > * New search group type for SRU library services > * Add a default search group server for Library of Congress SRU service > > Bugs Fixed > * Fix text selection or insertion after pasting in text fields for field names or cite keys > * Fix opening a URL with BibDesk > * Fix some localized terms > * Avoid blocking when running import script command > * Fix support for group ranges in AppleScript > > _______________________________________________ > Bibdesk-announce mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-announce |
From: Christiaan H. <cmh...@gm...> - 2025-05-06 08:49:26
|
The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.7, is now available. We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at https://sourceforge.net/projects/bibdesk/ <https://sourceforge.net/projects/bibdesk/> or by visiting the BibDesk home page at https://bibdesk.sourceforge.io/ <https://bibdesk.sourceforge.io/> or by following the link below, which will begin immediate download: https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download <https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download> For those interested follow the full release notes for this version. Release notes for BibDesk version 1.9.7 New Features * New search group type for SRU library services * Add a default search group server for Library of Congress SRU service Bugs Fixed * Fix text selection or insertion after pasting in text fields for field names or cite keys * Fix opening a URL with BibDesk * Fix some localized terms * Avoid blocking when running import script command * Fix support for group ranges in AppleScript |
From: Christiaan H. <cmh...@gm...> - 2025-02-18 16:29:26
|
Correction, that is not true. But including it as an optional (or default) field in the type info does include it in the minimal bibbtex. Christiaan > On 7 Feb 2025, at 23:11, Christiaan Hofman <cmh...@gm...> wrote: > > That is basically correct. Or you check the “is default” check button in the Custom BibTeX Fields table. > > Christiaan > >> On 7 Feb 2025, at 21:25, Nathan <nat...@gm...> wrote: >> >> Andreas: If I am not mistaken, fields for the Minimal BibTeX Record are specified in BibDesk's Default Fields preference pane in the "Custom BibTeX Types and Fields" section. Simply add "Doi" to the "Optional Fields" column there, and it will be included in a Minimal BibTeX Record. >> >> Nathan >> >>> On Feb 7, 2025, at 12:33 PM, Fischlin Andreas <and...@en...> wrote: >>> >>> Hi all, >>> >>> I have a suggestion for the 'Menu command 'Edit -> Copy As -> Minimal BibTeX Record'. I suggest it should also include the field 'doi' given today's increasingly ubiquitous >>> use of DOIs. >>> >>> Agreement / Disagreement? >>> >>> Regards, >>> Andreas |
From: Christiaan H. <cmh...@gm...> - 2025-02-07 22:11:26
|
That is basically correct. Or you check the “is default” check button in the Custom BibTeX Fields table. Christiaan > On 7 Feb 2025, at 21:25, Nathan <nat...@gm...> wrote: > > Andreas: If I am not mistaken, fields for the Minimal BibTeX Record are specified in BibDesk's Default Fields preference pane in the "Custom BibTeX Types and Fields" section. Simply add "Doi" to the "Optional Fields" column there, and it will be included in a Minimal BibTeX Record. > > Nathan > >> On Feb 7, 2025, at 12:33 PM, Fischlin Andreas <and...@en...> wrote: >> >> Hi all, >> >> I have a suggestion for the 'Menu command 'Edit -> Copy As -> Minimal BibTeX Record'. I suggest it should also include the field 'doi' given today's increasingly ubiquitous >> use of DOIs. >> >> Agreement / Disagreement? >> >> Regards, >> Andreas |
From: Nathan <nat...@gm...> - 2025-02-07 20:25:54
|
Andreas: If I am not mistaken, fields for the Minimal BibTeX Record are specified in BibDesk's Default Fields preference pane in the "Custom BibTeX Types and Fields" section. Simply add "Doi" to the "Optional Fields" column there, and it will be included in a Minimal BibTeX Record. Nathan > On Feb 7, 2025, at 12:33 PM, Fischlin Andreas <and...@en...> wrote: > > Hi all, > > I have a suggestion for the 'Menu command 'Edit -> Copy As -> Minimal BibTeX Record'. I suggest it should also include the field 'doi' given today's increasingly ubiquitous > use of DOIs. > > Agreement / Disagreement? > > Regards, > Andreas |
From: Fischlin A. <and...@en...> - 2025-02-07 20:07:43
|
Hi all, I have a suggestion for the 'Menu command 'Edit -> Copy As -> Minimal BibTeX Record'. I suggest it should also include the field 'doi' given today's increasingly ubiquitous use of DOIs. Agreement / Disagreement? Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin Formerly IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en... <mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.html <http://www.sysecol.ethz.ch/people/andreas.fischlin.html> +41 44 633-6090 phone +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ |
From: Alessandro P. <pi...@gm...> - 2024-10-24 02:03:25
|
That is because the way iPadOS works. All the app are containerized including Dropbox. The only app I know it can access other apps containers is the Files application (which is part of the OS). If that is the case, this means that Ref42 cannot access the container of Dropbox in the iPad. But it needs to download a cached local copy which it open with the system PDF viewer. I think the only possibility to do what you ask would be to have Ref42 have the option to upload the annotated file automatically on Dropbox and substitute the original file. That depends if the Dropbox API allows that. Simply upload the file with the same name will loose sync on BibDeak, because the file is linked with the descriptor, not the filename. Not sure how easy it is but we could ask the developer if he can take a look at it. On Wed, Oct 23, 2024, 8:02 PM M. Tamer Özsu via Bibdesk-users < bib...@li...> wrote: > I know this program and use it myself. The trouble is if you open a file > to read, it seems to download the file and if you annotate it, you need to > upload it and remember the folder it was in. Bibdesk maintains that > location without the need to upload. > > Perhaps I am doing something wrong. > > ==Tamer > > > ------ Original Message ------ > From "Alessandro Piovaccari" <pi...@gm...> > To "For general discussion about using BibDesk" < > bib...@li...> > Date 2024-10-23 3:28:38 PM > Subject Re: [Bibdesk-users] bibdesk on ipados > > The reading application for iPadOS to read Bibdesk .bib files and > automatically display or download the PDFs already exists. It actually > allows you to connect directly to Dropbox or other cloud file servers. > > The app has actually been there for a while and it is relatively well > maintained. I use it all the time. It is relatively well maintained and the > developer has been responsive to questions and suggestions. > > It is not easy to find and not well publicized, so here is the appstore > link to access it: > https://apps.apple.com/us/app/references/id1481843213?platform=ipad > > A little bit more info by the developer: https://benburton.org/references/ > > Enjoy! > --AP > > > On Wed, Oct 23, 2024 at 10:55 AM Fischlin Andreas < > and...@en...> wrote: > >> I agree, at least a reading option would be quite handy. However, I fear, >> a version comparable in functionality would be very difficult to implement >> and IMHO not even desirable, as I cannot imagine to efficiently maintain my >> literature collection on an iPad. >> >> Just my two cents, >> Andreas >> >> ETH Zurich >> Prof. em. Dr. Andreas Fischlin >> Formerly IPCC Vice-Chair WGII >> Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics >> CHN E 24 >> Universitaetstrasse 16 >> <https://www.google.com/maps/search/Universitaetstrasse+16+8092+Zurich+SWITZERLAND?entry=gmail&source=g> >> 8092 Zurich >> <https://www.google.com/maps/search/Universitaetstrasse+16+8092+Zurich+SWITZERLAND?entry=gmail&source=g> >> SWITZERLAND >> <https://www.google.com/maps/search/Universitaetstrasse+16+8092+Zurich+SWITZERLAND?entry=gmail&source=g> >> >> and...@en... >> www.sysecol.ethz.ch/people/andreas.fischlin.html >> >> +41 44 633-6090 phone >> +41 79 595-4050 mobile >> >> Make it as simple as possible, but distrust it! >> ________________________________________________________________________ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 19 Oct 2024, at 03:13, M. Tamer Özsu via Bibdesk-users < >> bib...@li...> wrote: >> >> I am trying to move more of my reading and marking technical papers to my >> iPad and everyday I rue the absence of bibdesk in ipados. I'd pay for it to >> be avaialable there. Nothing compares. >> >> Just thinking out loud. >> >> ==Tamer >> -- >> M. Tamer Özsu >> University of Waterloo >> Cheriton School of Computer Science >> https://cs.uwaterloo.ca/~tozsu >> >> >> >> _______________________________________________ >> Bibdesk-users mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users >> >> >> _______________________________________________ >> Bibdesk-users mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-users >> > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > |
From: M. T. Ö. <oz...@ma...> - 2024-10-24 01:02:03
|
I know this program and use it myself. The trouble is if you open a file to read, it seems to download the file and if you annotate it, you need to upload it and remember the folder it was in. Bibdesk maintains that location without the need to upload. Perhaps I am doing something wrong. ==Tamer ------ Original Message ------ >From "Alessandro Piovaccari" <pi...@gm...> To "For general discussion about using BibDesk" <bib...@li...> Date 2024-10-23 3:28:38 PM Subject Re: [Bibdesk-users] bibdesk on ipados >The reading application for iPadOS to read Bibdesk .bib files and >automatically display or download the PDFs already exists. It actually >allows you to connect directly to Dropbox or other cloud file servers. > >The app has actually been there for a while and it is relatively well >maintained. I use it all the time. It is relatively well maintained and >the developer has been responsive to questions and suggestions. > >It is not easy to find and not well publicized, so here is the appstore >link to access it: >https://apps.apple.com/us/app/references/id1481843213?platform=ipad > >A little bit more info by the developer: >https://benburton.org/references/ > >Enjoy! >--AP > > >On Wed, Oct 23, 2024 at 10:55 AM Fischlin Andreas ><and...@en...> wrote: >>I agree, at least a reading option would be quite handy. However, I >>fear, a version comparable in functionality would be very difficult to >>implement and IMHO not even desirable, as I cannot imagine to >>efficiently maintain my literature collection on an iPad. >> >>Just my two cents, >>Andreas >> >>ETH Zurich >>Prof. em. Dr. Andreas Fischlin >>Formerly IPCC Vice-Chair WGII >>Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics >>CHN E 24 >>Universitaetstrasse 16 >>8092 Zurich >>SWITZERLAND >> >>and...@en... >>www.sysecol.ethz.ch/people/andreas.fischlin.html >> >>+41 44 633-6090 phone >>+41 79 595-4050 mobile >> >> Make it as simple as possible, but distrust it! >>________________________________________________________________________ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>>On 19 Oct 2024, at 03:13, M. Tamer Özsu via Bibdesk-users >>><bib...@li...> wrote: >>> >>>I am trying to move more of my reading and marking technical papers >>>to my iPad and everyday I rue the absence of bibdesk in ipados. I'd >>>pay for it to be avaialable there. Nothing compares. >>> >>>Just thinking out loud. >>> >>>==Tamer >>>-- >>>M. Tamer Özsu >>>University of Waterloo >>>Cheriton School of Computer Science >>>https://cs.uwaterloo.ca/~tozsu >>> >>> >>> >>>_______________________________________________ >>>Bibdesk-users mailing list >>>Bib...@li... >>>https://lists.sourceforge.net/lists/listinfo/bibdesk-users >> >>_______________________________________________ >>Bibdesk-users mailing list >>Bib...@li... >>https://lists.sourceforge.net/lists/listinfo/bibdesk-users |
From: Alessandro P. <pi...@gm...> - 2024-10-23 19:29:04
|
The reading application for iPadOS to read Bibdesk .bib files and automatically display or download the PDFs already exists. It actually allows you to connect directly to Dropbox or other cloud file servers. The app has actually been there for a while and it is relatively well maintained. I use it all the time. It is relatively well maintained and the developer has been responsive to questions and suggestions. It is not easy to find and not well publicized, so here is the appstore link to access it: https://apps.apple.com/us/app/references/id1481843213?platform=ipad A little bit more info by the developer: https://benburton.org/references/ Enjoy! --AP On Wed, Oct 23, 2024 at 10:55 AM Fischlin Andreas < and...@en...> wrote: > I agree, at least a reading option would be quite handy. However, I fear, > a version comparable in functionality would be very difficult to implement > and IMHO not even desirable, as I cannot imagine to efficiently maintain my > literature collection on an iPad. > > Just my two cents, > Andreas > > ETH Zurich > Prof. em. Dr. Andreas Fischlin > Formerly IPCC Vice-Chair WGII > Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics > CHN E 24 > Universitaetstrasse 16 > 8092 Zurich > SWITZERLAND > > and...@en... > www.sysecol.ethz.ch/people/andreas.fischlin.html > > +41 44 633-6090 phone > +41 79 595-4050 mobile > > Make it as simple as possible, but distrust it! > ________________________________________________________________________ > > > > > > > > > > > > > > > > On 19 Oct 2024, at 03:13, M. Tamer Özsu via Bibdesk-users < > bib...@li...> wrote: > > I am trying to move more of my reading and marking technical papers to my > iPad and everyday I rue the absence of bibdesk in ipados. I'd pay for it to > be avaialable there. Nothing compares. > > Just thinking out loud. > > ==Tamer > -- > M. Tamer Özsu > University of Waterloo > Cheriton School of Computer Science > https://cs.uwaterloo.ca/~tozsu > > > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > |
From: Fischlin A. <and...@en...> - 2024-10-23 15:55:41
|
I agree, at least a reading option would be quite handy. However, I fear, a version comparable in functionality would be very difficult to implement and IMHO not even desirable, as I cannot imagine to efficiently maintain my literature collection on an iPad. Just my two cents, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin Formerly IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en... <mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.html <http://www.sysecol.ethz.ch/people/andreas.fischlin.html> +41 44 633-6090 phone +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ > On 19 Oct 2024, at 03:13, M. Tamer Özsu via Bibdesk-users <bib...@li...> wrote: > > I am trying to move more of my reading and marking technical papers to my iPad and everyday I rue the absence of bibdesk in ipados. I'd pay for it to be avaialable there. Nothing compares. > > Just thinking out loud. > > ==Tamer > -- > M. Tamer Özsu > University of Waterloo > Cheriton School of Computer Science > https://cs.uwaterloo.ca/~tozsu > > > > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users |
From: M. T. Ö. <oz...@ma...> - 2024-10-19 01:13:30
|
I am trying to move more of my reading and marking technical papers to my iPad and everyday I rue the absence of bibdesk in ipados. I'd pay for it to be avaialable there. Nothing compares. Just thinking out loud. ==Tamer -- M. Tamer Özsu University of Waterloo Cheriton School of Computer Science https://cs.uwaterloo.ca/~tozsu |
From: Christiaan H. <cmh...@gm...> - 2024-10-18 09:02:11
|
The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.6, is now available. We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at https://sourceforge.net/projects/bibdesk/ <https://sourceforge.net/projects/bibdesk/> or by visiting the BibDesk home page at https://bibdesk.sourceforge.io/ <https://bibdesk.sourceforge.io/> or by following the link below, which will begin immediate download: https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download <https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download> For those interested follow the full release notes for this version. Release notes for BibDesk version 1.9.6 Bugs Fixed * Fix links to internal pages in web group on newer OS systems * Use appropriate default encoding for reading text * Interpret missing dates in smart group conditions as far in the past * More efficient rebuilding of field groups * Fix selection from .aux file generated by biblatex * Auto-complete Location field * Include enclosing folder for linked files in exported archive |