<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Richard,<div class=""><br class=""></div><div class="">-------</div><div class="">Apparently a couple of issues showed up in Skim regarding PDFKit. It looks like the developer was able to find a workaround though:<br class=""><br class=""><a href="https://sourceforge.net/p/skim-app/bugs/1106/" class="">https://sourceforge.net/p/skim-app/bugs/1106/</a><br class=""><br class="">I use Skim, but I’m still trying to verify if Capture One Pro has been fixed in regard to Sierra, so I haven’t upgraded to Sierra yet myself and can’t personally verify any of this.<br class=""><br class="">Richard Séguin<br class=""><div class="">--------</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Do you have contact with the Skim developers. If so, you might want to pass along this information.</div><div class=""><br class=""></div><div class="">There is definitely a bug in the PDF search routine in PDFKit under Sierra. I reported this bug to Apple, but haven't had a reply. TeXShop has a workaround for the bug.</div><div class=""><br class=""></div><div class="">Here is a description. </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Preliminary Information:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Asynchronous searches can be done either by responding to notifications</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>or by implementing documentDidBeginDocumentSearch, documentDidEndPageFind,</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>documentDidFindMatch, and documentDidEndDocumentSearch. I suspect both</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>methods will see the same bug, but my application implements these calls</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>and does not use notifications.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>The Bug:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>PDFKit contains two routines, findString and beginFindString. The first is for </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>searching for the first match to a string, and the second is for an asynchronous</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>call which will produce a list of matches.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>A little debugging on El Capitan shows that "documentDidFindMatch" is not called</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>following a call to findString, but is called many times following a call to beginFindString.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>The same debugging on Sierra shows the reverse. It is as if the PDFKit team just</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>switched findString and beginFindString by mistake.</div><div class=""><br class=""></div><div class="">And indeed, my patch was simply to call findString rather than beginFindString, but only on Sierra. I'll have to release a new version as soon as Apple fixes this bug.</div><div class=""><br class=""></div><div class="">Dick Koch</div></div></body></html>