Jump to content

CJK

Member
  • Content Count

    79
  • Joined

  • Last visited

  • Days Won

    7

CJK last won the day on May 15 2019

CJK had the most liked content!

About CJK

  • Rank
    Member

Contact Methods

  • Website URL
    chri.sk

Profile Information

  • Location
    UK

Recent Profile Visitors

1,234 profile views
  1. That's good to hear. However, it was still an error that occurred in one file, so does require fixing, as there may be other PDFs that have blank pages. I've updated the file on GitHub with a fix for that, and a couple of other minor adjustments that I also realised were potential weak spots in those sorts of one-off situations. No idea I'm afraid. That one will be down to the language tagging function, which isn't something I'm able to change. Mojave does actually have a newer language detection class called NLLanguageRecognizer, which I'm uncertain what the differe
  2. Would you mind doing me a favour and just sending me the PDFs that you are using for testing purposes ? That way, I can see what sorts of content you're dealing with. This latest error, whilst very similar in nature to the one affecting the Title of the PDF document, seems odd that it would arise when dealing with a page from the PDF. It implies that there was no language detected, which in turn implies the page had no text. I can perhaps believe this might be the case for one random PDF file, but if you're presumably testing different files, then the others ought to work.
  3. Why did you post the same problem from earlier ? That one has been dealt with. You've posted a screen shot that shows you're using an older version of the script.
  4. Change these lines: set PDFTitleLang to (NSLinguisticTagger's ¬ dominantLanguageForString:PDFTitle) langs's setValue:1 forKey:PDFTitleLang to this: tell PDFTitle to if missing value ≠ it then tell ¬ (NSLinguisticTagger's dominantLanguageForString:it) to if ¬ missing value ≠ it then langs's setValue:1 forKey:it File updated on GitHub.
  5. *Sigh* My guess here is that the property of the PDF's attributes are specific to ones locale, and so your metadata item that holds the document's title is likely not called Title, but possible Titre. To confirm my hunch, you could change this line: set PDFTitle to the PDF's documentAttributes()'s |Title| as text to this: error PDF's documentAttributes() as record which will show you what the attribute names and values are in the error dialog that pops up. It's also possible that the specific metadata item for the
  6. The Run Script action, particularly relevant to osascript, appears to return the result of the script as text that is terminated with a line break character. This causes problems when the script returns a file path, which gets fed into the subsequent node of the workflow that is expecting to receive a file path that points to an existing file, but instead receives a file path that points to a non-existent file because of the extra character in its name. https://transfer.sh/LEmG3/Bug Report.alfredworkflow The workflow demonstrates the phenomenon. It simply displays an
  7. That's ok. You didn't tag me correctly. The correctly-tagged name will appear in purple. When you type @CJK, you should obtain a list of users that contain these letters in their username, and you can click on the appropriate one. Erm... Yeah, that's because you double-spaced the whole script. You've got a blank line in between every non-blank line. I have no idea how you accomplished that. I did a copy-n-paste test from my previous post and it pasted correctly. This is really helpful actually, because it finally pinpoints the nature of the er
  8. Great. Always happy to hear thoughts/comments/etc.
  9. @jmm28260 Sorry for the delay—been unwell. (Also, it's a good idea to tag the person to whom you're replying in your post using the @ symbol followed by their username, otherwise they won't necessarily be notified by your reply; or, at least, I'm not, despite having the option selected). OK, well done for finding those bits and pieces. I'll leave those for you to attempt to implement if you really feel any of them are the problem. I don't have Mojave and I don't intend to, so those recommendations aren't really something I can play around with. In the
  10. It's still showing that you've set the input folder to one thing, and the output folder to another. I can even see you edited the path of the directory variable to lead to a second folder called 2. Renommer When I assigned the variable directory back to both the input and the output folders, then changed the path of directory to point to my test folder where I copied in a bunch of PDFs, the workflow ran as expected. My suggestion is that you first try and use the workflow exactly as I've laid out, and then you can play around with it a bit more when you are more familiar with
  11. No, I can't see, because you cut off the top of the workflow, so only the output folder was visible. Anyway, let's try again. Please upload your correct workflow, and I'll have another look.
  12. So that was a lie: In the first action, you have the search folder set to 1. OCR. In the second action, you changed the output folder to Desktop. Now compare it with the workflow that I sent to you: Both the search directory and the output directory are the same, and I created a dedicated variable for it that holds the path. It's called directory and it's stored with the Automator variables that are accessible at the bottom of the window by clicking one of the buttons down there. Double-click the directory variable, and you can set t
  13. @jmm28260 OK, thanks for this. Would you mind uploading your workflow as it is and I'll take a look at it on my system, otherwise we could spend days going back and forth here. I think that'll be easiest for us both.
  14. As a tip to help get your problems solved faster, it's typically not very useful when you state that something doesn't work, then ask if I know what's wrong. I need a lot more information than that to be able to diagnose the potential issues. The dialog, whilst a sensible thing to screenshot and share, is sadly not especially helpful in this instance, but that's Automator's fault, not yours. It gives the vaguest errors, by informing you that there's a problem, and then assuming we all love needles in haystacks. What you should do first is edit the AppleScript and remove the l
  15. Well, that took much more than just a minute. Partly because your workflow was just kinda ugh, and partly because Objective-C is really bloody annoying on occasion, and the AppleScript needed to be re-written to cope with multiple file inputs, and because Automator can't do repeat loops by itself. Here's a screenshot of the Automator workflow, which now only has four actions: The modified AppleScript for use in the Run AppleScript action is below. Largely, the screenshot and script are for the benefit of anyone viewing this post at a later date, from which they can piece
×
×
  • Create New...