<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="">Dick,<div class=""><br class=""></div><div class="">No, I don’t have any direct contact with the developers. As far as I know, the only way to contact them is through the forum </div><div class=""><br class=""></div><div class=""><a href="https://sourceforge.net/p/skim-app/bugs/" class="">https://sourceforge.net/p/skim-app/bugs/</a> </div><div class=""><br class=""></div><div class="">I think you need to somehow establish yourself with a user-id and password. You have to create a “ticket” for a new issue. (This is really clumsy compared to working with the TeXShop or BBEdit developers.) If I still have a valid id/password, I don’t even remember what it is. Bottom line: you’re welcome to jump through the hoops yourself and report your findings to Christiaan Hofman.</div><div class=""><br class=""></div><div class="">I just noticed at the above link that Skim is also having a few other problems that they have found workarounds for.</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><br class=""></div><div class=""><div><div class="">On Sep 23, 2016, at 2:26 PM, Richard Koch <<a href="mailto:koch@uoregon.edu" class="">koch@uoregon.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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></div>----------- Please Consult the Following Before Posting -----------<br class="">TeX FAQ: <a href="http://www.tex.ac.uk/faq" class="">http://www.tex.ac.uk/faq</a><br class="">List Reminders and Etiquette: <a href="https://www.esm.psu.edu/~gray/tex/" class="">https://www.esm.psu.edu/~gray/tex/</a><br class="">List Archives: <a href="http://dir.gmane.org/gmane.comp.tex.macosx" class="">http://dir.gmane.org/gmane.comp.tex.macosx</a><br class=""> <a href="https://email.esm.psu.edu/pipermail/macosx-tex/" class="">https://email.esm.psu.edu/pipermail/macosx-tex/</a><br class="">TeX on Mac OS X Website: <a href="http://mactex-wiki.tug.org/" class="">http://mactex-wiki.tug.org/</a><br class="">List Info: <a href="https://email.esm.psu.edu/mailman/listinfo/macosx-tex" class="">https://email.esm.psu.edu/mailman/listinfo/macosx-tex</a><br class=""></div></div><br class=""></div></body></html>