Dear Peter,
Sorry, it is very difficult to understand what your actual problem is. First I
see no problem whatsoever in BD, nor in the bib file generated, nor in the
preview and most of all I do not understand why you try to do something with
AppleScripts. I base this conclusion on trying to repeat your problem using
your example. I can't.
2) I clicked on BD's Import button and the record was correctly imported into
BD, no errors encountered, and all is as it should. I see no problem there.
3) The Address field contains the string "PORTERS SOUTH, 4 CRINAN ST, LONDON N1
9XW, ENGLAND" correctly as it should be, though I don't like the capitalization
and you could edit that. But I guess that is beside the point.
4) If I do (still in BD) menu command "Window -> TeX Preview" I encounter no
errors and the opened preview window shows the record fine. Even the
capitalization problem is gone.
So where is a problem?
a) Do you want an AppleScript to edit any of the fields in that record? If yes,
why? What should be the purpose?
b) Curly braces do not protect anything. We are not talking about shell
scripts, we have BibTeX encoded data stored on bib-files that are managed by
BD. Curly braces merely delimit the begin and end of fields in the records and
enclose the entire record. They serve any scanner to delimit information and
correctly interpret begin and end of records and fields. Moreover curly braces
may be used within fields to encode special characters, abbreviations, macros
etc. Ex.: Author = {Kurt G{\"o}del}, Title = {The \TeX{}book}, . The field
author is very special, since it is treated into several subfields
automatically and uses for convenience reasons commas and optionally curly
braces to delimit its subfields. That may be the source for your
misinterpretation that you protect something with curly braces. See e.g. Kopka
& Daly, 2004, p. 235 for more on this.
You write: "However, this citation causes an error using my tex preview
template (below, require biblatex). The relevant part of the log is:
Too many commas in name 1 of "PORTERS SOUTH, 4 CRINAN ST, LONDON N1 9XW,
ENGLAND" for entry cite-key"
This indicates that there is an error in your tex preview template. It seems
you entered the content of the address field into the author field or made some
other error causing such an interpretation by the BibTeX interpretation. This
has all absolutely nothing to do with curly braces nor AppleScripts AFAIK. If
my interpretation is correct, fix first your preview template so that no longer
any address information is interpreted as an author field.
c) Have you indeed changed any templates? If yes, reverse that and your
problems might be gone. Writing a TeX paper using BibTeX will only need the
correctly stored bib file and should be independent from any preview template.
There seems to be nothing wrong in your case with all the software components
involved there, except for those you may have tampered with. You may have
altered preview templates or otherwise deviated from a default BD installation
or you have wrongly changed BibTeX styles you use in your TeX setup.
d) Why writing a bug report? AFAI can see there is no bug anywhere in BD nor
its default templates as used by Preview, nor is there any real biblatex
problem involved. It seems you would have to write the bug report to yourself.
;-)
Hope this clarifies some of the issues.
Regards,
Andreas
Cited References:
------------------------
Kopka, H. & Daly, P. W., 2004 (ed. 4). Guide to LaTeX. Addison-Wesley: Boston,
US. 597pp. Ko089
ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND
[email protected]
www.sysecol.ethz.ch
+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 221-4657 mobile
Make it as simple as possible, but distrust it!
________________________________________________________________________
On 03/Apr/2010, at 00:34 , Peter Cowan wrote:
> On Fri, Apr 2, 2010 at 2:13 PM, Christiaan Hofman <[email protected]> wrote:
>>
>> On Apr 2, 2010, at 21:54, Peter Cowan wrote:
>>
>>> On Fri, Apr 2, 2010 at 9:53 AM, Christiaan Hofman <[email protected]>
>>> wrote:
>>>>
>>>> On Apr 1, 2010, at 23:29, Peter Cowan wrote:
>>>>
>>>>> On Thu, Apr 1, 2010 at 2:03 PM, Christiaan Hofman <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> On Apr 1, 2010, at 22:15, Peter Cowan wrote:
>>>>>>
>>>>>>> I'm using biblatex in the TeX preview window. And, since I often
>>>>>>> import directly from ISI using the Web of Science Search function, I
>>>>>>> get regular errors related to commas in the address or institution
>>>>>>> field. Perhaps there is a solution through biblatex to this problem,
>>>>>>> but I'm fine with either protecting or deleting the
>>>>>>> Address/Institution field on import.
>>>>>>>
>>>>>>> Script hooks seem like the perfect solution to this problem, but I am
>>>>>>> not an applescript users. I've tried to cobble something together
>>>>>>> based on the available example and got the following which doesn't
>>>>>>> appear to work, on import (from Web of Science) nothing happens no
>>>>>>> errors no braces. Any nudges in the right direction are appreciated.
>>>>>>>
>>>>>>> I apologize if this has been discussed on the list before, my searches
>>>>>>> did not reveal anything aside from confirmation of the biblatex TeX
>>>>>>> preview issue.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>> [snip old code]
>>>>>>
>>>>>> This won't work, because you call the external scripts outside the
>>>>>> "perform BibDesk action..." handler. The script hook will only call that
>>>>>> handler, so anything outside it (like defining the protectLib and
>>>>>> errorLib) will be ignored. Therefore reference to those external scripts
>>>>>> will fail. You'll have to move everything to inside the script hook
>>>>>> handler.
>>>>>
>>>>> Christiaan,
>>>>>
>>>>> Thanks for the reply, I've moved the load script calls inside of the
>>>>> handler, but alas it still doesn't work. The current version is
>>>>> below.
>>>>>
>>>>> I apologize for being such an applescript newb, but is there a
>>>>> workflow you follow for developing this applescripts, e.g. debugging
>>>>> hints, setting "breakpoints" etc.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Peter
>>>>
>>>>
>>>> [snip]
>>>>
>>>> BTW, another possibility is that this actually works, but you expect it to
>>>> do something different from what it actually does. What this most
>>>> certainly does NOT do is to enclose the Address value in braces, and the
>>>> check you added make me think that that's what you (wrongly) expect it to
>>>> do. So perhaps you should also say what you expect it to do, and what you
>>>> did exactly to make it do that, perhaps with explicit samples.
>>>
>>> Christian and Fischlin,
>>>
>>> Thanks for your replies. Indeed I'm trying to wrap the Address Field
>>> in curly braces so that biblatex won't puke on those bib items. I
>>> thought that wrapping something in braces was called protecting, but
>>> perhaps I am wrong.
>>>
>>> You are correct the above script most definitely did not do what I was
>>> hoping for.
>>>
>>> An explicit example:
>>>
>>> I usually use the Web of Science SCI search to import references. If
>>> I search for au=(watson AND crick) the first hit is
>>>
>>> CRICK, FHC and WATSON, JD. 1956. STRUCTURE OF SMALL VIRUSES. Nature.
>>> 177(4506):473-475.
>>>
>>> However, this citation causes an error using my tex preview template
>>> (below, require biblatex). The relevant part of the log is:
>>>
>>> Too many commas in name 1 of "PORTERS SOUTH, 4 CRINAN ST, LONDON N1
>>> 9XW, ENGLAND" for entry cite-key
>>>
>>> If I change the address field to
>>>
>>> {PORTERS SOUTH, 4 CRINAN ST, LONDON N1 9XW, ENGLAND}
>>>
>>> it is compiled and previewed correctly.
>>>
>>
>> That sounds like a totally different problem. The warning says it's
>> interpreting this as a name. So either you've put the address in an author
>> field or something, or biblatex has a problem. It should never interpret an
>> address as a name IMHO.
>
> This is from a direct import using the "Import" button while searching
> WOS from bibdesk. I agree it seems like a biblatex problem to me, but
> I've not found mention of it on the biblatex list, I may send a bug
> report that way.
>
> This is the how the above example is imported by BibDesk:
>
> @article{CRICK.F:1956,
> Address = {PORTERS SOUTH, 4 CRINAN ST, LONDON N1 9XW, ENGLAND},
> Author = {CRICK, FHC and WATSON, JD},
> Date-Added = {2010-04-02 15:28:17 -0700},
> Date-Modified = {2010-04-02 15:28:17 -0700},
> Isi = {A1956ZQ08700022},
> Isi-Recid = {3737785},
> Isi-Ref-Recids = {1399833 25231 154301 694402 25230 239834 3611023
> 3395518 3500753 3437398 176937 3474554 175967 2741553 137080 43856
> 3395520 3397795 3437394 3742607 103203 3611269 2741574 3395809 3397793
> 261765 3649114 665053 3742608 2741559 3742609 482156},
> Journal = {Nature},
> Number = {4506},
> Pages = {473-475},
> Publisher = {MACMILLAN MAGAZINES LTD},
> Times-Cited = {327},
> Title = {STRUCTURE OF SMALL VIRUSES},
> Volume = {177},
> Year = {1956},
> Bdsk-Url-1 =
> {http://gateway.isiknowledge.com/gateway/Gateway.cgi?GWVersion=2&SrcAuth=Alerting&SrcApp=Alerting&DestApp=WOS&DestLinkType=FullRecord;KeyUT=A1956ZQ08700022}}
>
>>> The applescript I sent before was an effort to do that wrapping on
>>> import. I however was unable to get the protectLib to work at all
>>
>> That's probably because you haven't really used it. This protects individual
>> words or phrases (which is really the correct thing to do in bibtex), and
>> you have to tell it which words and phrases to protect. Just enclosing a
>> value in braces is crude and generally the wrong thing to do, because the
>> capitalization is supposed to be determined by the style and not by the
>> data, except for certain special words (like acronyms.)
>
> Ahh. I agree that bracing the whole field is not a good strategy.
> However, I hardly ever use the Address field (for journal articles it
> is usually the publishers address and thus not in the styles I use).
> But, bracing it is safer than deleting it for the cases when it is
> used.
>
>>
>>> so
>>> I ended up with this *working* script hook. A couple of caveats, the
>>> errorLib has never produced anything to me, it seem unlikely given my
>>> applescript skills, that I produced no errors.
>>
>> Errors really mean errors, in that they would normally fail the script if
>> you don't escape them.
>>
>>> And, secondly this
>>> method won't, of course, catch cases where the field is already in
>>> braces, so some Address fields could end up double wrapped.
>>> Suggestions for improvements are welcome.
>>
>> Define the following in your applescript and use it instead of
>> protectString():
>>
>> on encloseInBraces(theString)
>> if (theString is "") or (character 1 of theString is "{" and character
>> -1 of theString is "}") then
>> return theString
>> else
>> return "{" & theString & "}"
>> end if
>> end encloseInBraces
>>
>
> Thanks for this.
>
> Peter
>
>>
>> Christiaan
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Bibdesk-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Bibdesk-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bibdesk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
