zeitlings

That being said, I think some improvements would still be nice. - [Like having *renditions* in links](https://italics.ignor.ed) - Supporting footnotes[^1]. ... [^1]: Or at least to make sure this syntax doesn't produce unexpected results. - Some way to make ==highlights== - Or better yet, to support Admonition Panels to draw special attention to something in the documentation: > **Note** > This is a note > **Warning** > This is a warning

Interesting! Alfred seems to cache the images on disk though: ~/Library/Application Support/Alfred/Databases/clipboard.alfdb.data/399627828244ea16ec127a51c3617aa532565270.tiff. I suppose all that is needed is for the file path to be exposed from the clipboard history, then you could push it to the buffer, copy it, or act on it through the Universal Action view.

GIF from Video The workflow allows you to convert video of popular formats to animated GIFs. To do this, it uses ffmpeg as a dependency. Usage Note Either send a video to the workflow's File Action or invoke the workflow using the keyword and search for the video file you want to convert. Then select the image size you want the resulting GIF to have from the list to start the conversion. You can also specify the desired number of frames per second (FPS) in the workflow configuration to further influence the size of the exported file.

Via the pointers Vitor gave elsewhere: Keyboard Brightness Adjust the keyboard brightness either by using the keyword or by setting up custom shortcuts. When using the keyword type > to increase the brightness type < to decrease the brightness

Have you checked if it is a sandbox thing that has to be (and can be) set to expose events to the system? Perhaps there's also a difference when trying to build it via SPM vs. Xcode. Why that is, I don't know, but I had different behaviours before. The script version works fast and stable enough for me at the moment 🤷‍♂️. I'll make it available as a workflow for now, at least until your replacement is ready.

Why isn't this a proper workflow yet? This is great 😄. I've been looking for one that controls keyboard brightness myself a while ago. I'll whip one up real quick.

v1.2.0 Added File Action utility to get bundle identifiers from apps Added useful failure messages Added configurable keyword Added more default options Added new icon Updated documentation

Not an automation task and I'm not sure how you would use it in the, I assume, Label Color Tag workflow, but you could get the tags like this: mdfind -onlyin ~/Documents "kMDItemUserTags=*" | xargs -I{} mdls -name kMDItemUserTags {} | sed -e 's/kMDItemUserTags = (//; s/)//' -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' -e '/^$/d' | tr -d ',"' | sort | uniq Depending on how many tagged files you have on your system, this may take a while. To search the entire filesystem, you can replace ~/Documents with just ~, which could take quite a long while. To have a continuous stream of (unfiltered) tags, you can try this in the terminal to make sure that it works: mdfind -onlyin ~ "kMDItemUserTags=*" | xargs -I{} mdls -name kMDItemUserTags {} | sed -e 's/kMDItemUserTags = (//; s/)//' -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' -e '/^$/d' -e 's/\"//g' -e 's/\,//' Press ctrl+C to stop the process.

There’s no macOS API to retrieve all your custom tags. While this is true, I think I still found a decent way to make autosuggest happen using the mdfind and mdls commands. mdfind -onlyin ~/PATH/TO/SOURCE "kMDItemUserTags=PREFIX*" mdls -name kMDItemUserTags "$FILE_PATH" @vitor I am uploading a version of your workflow where I have been playing with this concept. I'm sure I haven't tested all possible scenarios and a lot could be improved with caching, but it works pretty well so far 🤗. https://bashupload.com/0_G9I/uzu8e.alfredworkflow

The filetype refers to the Uniform Type Identifier of a given file. "Desktop", for example, has the UTType public.folder. Some file main.swift has the UTType public.swift-source, etc. MacOS will bring up a generic icon associated with that "filetype", which should be fast. You can look up UTTypes in the Terminal if you'd like: mdls -name kMDItemContentType -raw ~/Desktop

Perhaps there is an option... You could recursively traverse the entire file system and collect all the tags that way 😄

Hey, two suggestions for the configuration builder: Drag-and-Drop to reorder the fields (please) Add option-sets as a new base type What I have in mind is very similar to "Popup Selection". You can define a set of items, but instead of allowing only one of the options to be selected, all options can be added as needed. What can be added is predefined, which prevents the user from passing incorrect values to the workflow. Take, for example, the language options in the OCR workflow. Instead of copying and pasting "es-ES, pt-BR, zh-Hans", the NSTokenField would autocomplete to the appropriate option (based on the item label).

Aw dayum, that's neat. Nice addition!

I find it useful, so much so that I just recreated it, too 😅

New File The workflow does something very simple, it allows you to quickly create new files in the Finder. If, like me, you know that awkward dance you sometimes have to do, just to get a new text, source, or bib file, you might like this one. ‣ Download on Github ◂ Usage Keyboard Shortcut If the post-haste behavior is enabled, new files are created the same way as folders are when you use the shortcut (default: ⌥+⇧+N). Otherwise you will be prompted with the input mask where you can configure the file name and type. Keyword The workflow will pick up on your location in the Finder and create the new file there. If you use the keyword (default: new), the most recently used Finder window will be selected as the destination. If no Finder window is currently open, the file will be created in the configurable fallback location. Alternatively, press ⌘+↩ to explicitly specify an output location. Creating a New File ⌘ to view the full path to the target folder. ↩ to create the file with configured settings. ⌘+⇧+↩ to create the file with clipboard contents. ⌥+⇧+↩ to create the file without clipboard contents. TAB to accept and expand the auto-suggested filename. Bonus: In addition to all plain-text type files, the workflow can also quickly create docx, doc, odt, rtf, rtfd files and Xcode playgrounds. Configuration The Fallback Location will be used when activating the workflow with the keyword, but no Finder window is currently open. Otherwise the most recently used Finder window is used as destination. If the post-haste behavior is disabled, the shortcut will also prompt you with the input mask. If the option to create new files with the contents of the clipboard is disabled, you can still choose to create new files with the clipboard contents by using the input mask and enabling the correlating modifier. Similarly, you can opt out on a per-file basis.

Hey @TomBenz, fixed in v1.1.0! And a few more changes: v1.1.0 Fixed the displayname of folders containing a dot being cut off Added generic icon for PDF documents Improved fuzzy search Disabled the option to move items if the list is filtered

This time I wanted to get a bit more familiar with (zsh flavored) shell scripting. The result is Favorites, the spiritual successor of Faves, which was last maintained by @Tyler Eich if I'm not mistaken. Notwithstanding the fact that the successor still works well, this workflow is written 100% in shell and does not require Python 2.7 to be installed. I did some testing, but there might still be some bugs hiding. If you catch them, please bring them here 😄 ‣ Download ◂ Favorites Add files and folders to your list of favorites by using the workflow’s Universal Action. Quickly find them again by activating the workflow with the Keyword (default: fav) or by setting a hotkey of your choice. Usage Hints Press cmd+O or enter to open a file or folder. Add items with the workflow’s Universal Action. Modifiers: ctrl: Show full Path cmd: Reveal in Finder opt: Browse in Alfred cmd+shift: Move up opt+shift: Move down fn: Remove from Favorites shift or cmd+Y: Quicklook Preview Special Inputs Type :fav to open the list of favorites in your default text editor

It's true, the increase in file size can be significant. I did some comparisons with DEVONthink's OCR for your usual text-based PDF documents, which uses Abbyy's engine in the background. In some cases, I was able to get better results in terms of file size with the workflow, so I guess it can hardly be avoided. Abbyy's in-house application can export PDFs by applying MCR compression to the images, which is great and would be awesome to have access to. But that goes way beyond what I had in mind for the workflow 😂. What I find interesting is that the screenshots most likely don't have any previous text embedded in them, which should allow for a more efficient way to create the new PDF pages, and that the file size still escalates as it does. There is a difference between real-world image dimensions and device-specific metrics. Perhaps what looks like a rather modest screenshot could be a 4K ∞-DPI monstrosity? Image compression is its own subgenre, I suppose, and another rabbit hole to get lost in for sure. Maybe I'll look into it sometime in a moment of muse. You may want to take a look at @xilopaint's Alfred PDF Tools to reduce the pixel density of your document or to scale the images down before attempting the OCR. For really large documents, however, I would recommend to use, and I myself will continue use, the professional tools.

v1.2.3 • Fixed an error thrown due to missing workflow cache directory • Fixed snapshot tasks queuing up if they are started before the previous task has finished • Added explicit opt-out of Snapshot tasks while PDF conversions are running

Ah, thanks for reporting that! Looks like the cache folder (where the temporary progress file lives) has to be manually created first. If you'd like to run a quick test, you can replace the following line in both the Run Script and Script Filter objects. if [[ -f "${alfred_workflow_cache}/progress.txt" || -v pdf_path ]]; then With [[ -d "${alfred_workflow_cache}" ]] || mkdir -p "${alfred_workflow_cache}" if [[ -f "${alfred_workflow_cache}/progress.txt" || -v pdf_path ]]; then (And make sure to delete the manually created progress.txt again. If it exists, the workflow assumes that an OCR job is running.)

@sepulchra yes! 😁 @xilopaint yes! 😁 I have given the project a little more attention, i.e. fixed some bugs, implemented some optimizations and added a proper progress tracking system. There is now a light version to keep the binary-free workflow alive, and a plus version that adds the PDF processing to it. v1.2.2 (OCR+) Fixed low contrast output images produced for some PDF documents Added progress tracker for the document recognition process Added three options to handle document output: export to location, copy to same location and replace. Priority behavior: Replace > Copy > Export. Added new icons Improved output file size for PDF documents that do not already contain text

https://openai.com/pricing

v1.1.0 Behavior change: By default, all defined dictionaries are used. The previous “Main Dictionary” becomes the default fallback dictionary against which possible misspellings are checked. Indicators for the dictionary associated with an entry: They are visible using the ctrl modifier and in the title of the Quicklook preview. The workflow now doubles as a multilingual spell checker: Use the cmd modifier to paste the word into the frontmost application. Add deduplication of dictionary entries. Remove Wikipedia as an option as it is not functional.

😱 Try this! I managed to get some acceptable results. The internal font handling and bounding box scaling works with some heuristics for now, though. Also, since there's no progress tracking and the code is completely synchronous, it's best to test the workflow on small documents. Still, the debugger will log some landmarks that you can review after the fact. @sepulchra You're welcome 🤗 "OCRmyPDF" will most likely give you better results, and should probably remain your go-to if it is already set up. But at least here's a few steps towards a native solution 😁.

Ok, here's a follow-up. I was thinking about converting PDFs to searchable PDFs by embedding a hidden text layer. Turns out PDFKit doesn't provide any access to the underlying PDF content streams at all, and no alternative way to embed text layers. At best, the information can be inserted as annotations, which are not embedded statically, but as objects that you can change at will. This is rather annoying, because the Preview app shows that PDFKit is very much capable of embedding text layers. Example: When you open a PDF with no text or an image in the Preview app, the "Live Text" feature lets you select and copy recognized text as if OCR had been fully performed. When exporting the PDF you can even enable "Embed Text", which does exactly what we're trying to accomplish here. (And they do sell it as a feature of PDFKit). Anyway, as it stands now, it's a convoluted process I haven't made sense of yet. Pulling the plain text out of PDFs without an OCR layer isn't a problem, though. But I'm not convinced how useful that is ¯\_(ツ)_/¯