OCR SmartRule triggering inappropriately

I use the following smart rule to OCR records with no text layer; the principle is tried and tested, and previously worked flawlessly:

This rule has started triggering inappropriately. I have just saved a PDF with a text layer from Safari to DT Inbox; it immediately trigged the rule, and was OCR’d. I deactivated the rule and again saved the PDF to DT; this time no OCR was performed (confirming that it is the above rule performing the OCR). Checking this PDF with this script

tell application id "DNtp"
	set theRecords to selection
	repeat with theRecord in theRecords
		return word count of theRecord
	end repeat
end tell

shows the PDF to have 710 words. I can mark, copy and paste words from the PDF to a note, so the text layer is intact. Further experimentation shows that other smart rules can work on the PDF based on its text contents, so the contents are certainly accessible.

This rule only inappropriately triggers if I save the PDF from Safari to DT; if I print the exact same PDF from Safari to DT, the rule does not trigger. Here is an example PDF which triggers the rule for me on save, but not on print. This behaviour is certainly new, and may have appeared in 3.8.1 or Monterey 12.2/12.2.1; it’s not apparent to me that I have changed anything myself which could have triggered the change in behaviour.

Does it work as expected after removing the After Synchronization trigger? Most likely reason is that an automatic synchronization happens while the PDF document is indexed in the background (and therefore the word count is still 0).

1 Like

Nice idea - but yes, it still happens after I remove the After Sync trigger.

How do you exactly save to DEVONthink? To the inbox folder in the Finder?

Correct; in Safari I Command-S, select Inbox from the sidebar in the save dialog, select the save button.

(PS I have removed the AS action from the rule, too - the behaviour persists)

I think I can now confirm this is a regression of either 3.8.1 or macOS 12.2.1; the behaviour is not displayed by my second Mac, which is still running 3.8 and 12.2; I will confirm once I update macOS and or DT on that device, although I’m going to hold off, pending your further feedback.

Just fixed this, it’s actually a timing issue and existed since version 3.0.

1 Like

In that case I apologise for the delay in reporting it; I endeavour to do better next time :smiley: It would seem you haven’t fixed it on my Mac yet, though - when would you like to pop round to do it? And do you prefer tea or coffee? :smiley:

On a more serious note: Report to fix 2 hours, 17 minutes. I have worked with other companies where the hold time on the phone would have taken up most of that time; so - once again - thank you for your time, thank you for your work.

:grin:

…aaaand I can confirm the problem is fixed with 3.8.2 :smiley: So, that’s complaint to fix in less than 22 hours. That’s. Not. Bad.™

3 Likes