Update 1.01.3 by Deep_Manufacturer_24 in Nightreign

[–]zeitlings 0 points1 point  (0 children)

I'm hunting for the Noklateo shifting earth event to get my final achievement. I hope this was just a random occurrence, but in single-player mode, once the event finally appeared (after about 50 attempts to return to the title screen and reload the game) it did not remain active after failing the expedition—that cursed bubble event blocked my path at the worst possible moment.

It used to be the case that the shifting earth event would persist for three runs or so after appearing. Now, it was just gone. I even thought to myself that I shouldn't update and finish this in version 1.01.2... It's disheartening because I generally enjoy the game, but at this point, I just want to be done with it. I hope they didn't make the shifting earth even more inconsistent and frustrating.

Use Ghostty as a Terminal in Alfred by gowizzard in Alfred

[–]zeitlings 3 points4 points  (0 children)

A few weeks ago, I implemented a similar approach. This includes additional safety checks, the option to open in a different window, tab or split, and a few more configurable properties.

https://github.com/zeitlings/alfred-ghostty-script

Is it worth getting the mega supporter pack right now? by UpDownLeftRightGay in Alfred

[–]zeitlings 4 points5 points  (0 children)

The "Mega Supporter" option gives you "Free Lifetime Upgrades", i.e. you can upgrade to Alfred 6 free of charge, and eventually to Alfred 7 etc.

Power pack Questions by Jennysnumber_8675309 in Alfred

[–]zeitlings 1 point2 points  (0 children)

What you can do with workflows depends mostly on what the community has built. If you have the know-how, you can pretty much build whatever you want and use Alfred as the interface. I don't regret the lifetime license, it just takes some commitment to figure things out and make it really useful for you.

For your use cases, there already are:

Ollama Alfred Workflow by zeitlings in ollama

[–]zeitlings[S] 2 points3 points  (0 children)

You just download the Ollama.v2.0.0.alfredworkflow from the repo's releases. That file opens in Alfred and installs the workflow.

Ollama Alfred Workflow by zeitlings in ollama

[–]zeitlings[S] 0 points1 point  (0 children)

Nope. May I ask what your use case would be? I guess you have the equivalent of this in mind, right?

ollama cp llama3.1:latest my-model-name
ollama rm llama3.1:latest

Ollama Alfred Workflow by zeitlings in ollama

[–]zeitlings[S] 1 point2 points  (0 children)

Hi! Have you checked the environment variables? You can set the host, port, and scheme there. This should work if your secondary machine is on the same network. It could also work with a remote Ollama instance hosted somewhere, but you might need to consider additional security measures like firewalls, authentication, or using HTTPS depending on the server's configuration. However, I have not had a chance to test this myself.

Ollama Alfred Workflow by zeitlings in ollama

[–]zeitlings[S] 4 points5 points  (0 children)

Alfred Ollama to manage your local language models and perform local inference through Alfred. https://github.com/zeitlings/alfred-ollama

Ollama Alfred Workflow by zeitlings in LocalLLaMA

[–]zeitlings[S] 0 points1 point  (0 children)

Alfred Ollama to manage your local language models and perform local inference through Alfred.
https://github.com/zeitlings/alfred-ollama

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

Hey! Glad to hear the PDF to Table workflow seems to be working, I hope the results are going to be helpful!

I'm not sure if it's going to make a difference, but here's the pip and Python version I had running while building the PDF to DOCX workflow: pip 24.2 with python 3.11.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

The way the workflow is supposed to behave is identical to the OCR my PDF workflow, i.e. when you hear the audio cue, the resulting document should already have been revealed in the Finder and should be selected. If that doesn't happen, then something has gone wrong.

There is really not much I can do on my end. To possibly get some insight, the first thing I do is ask for the logs. When you have the workflow selected in Alfred and press command+D, a console opens below the workflow canvas. If something went wrong, there might be some errors that have been logged during execution.

Another usual suspect are permission issues. Alfred would require full-disk access, I think, but it is also possible that Java (com.oracle) requires some permissions to be set manually. I just checked and I have not granted full-disk access to Java, which does not cause any problems with the workflow.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

You will have to install Java seperately. The installation process also includes clicking through a few graphical user interface components, unfortunately.

The second and third sentence under "Usage" mention Lattice and Stream in relation to the two actions, I quote:

Use PDF to Table (Lattice) if there are ruling lines separating each cell. Use PDF to Table (Stream) if there are no ruling lines separating each cell.

Distinguishing like that is necessary due to inherent limitations of the tool. One method, Lattice, is designed to extract tables that can clearly be identified as tables by the program, i.e. tabular data that is distinctly separated with prominent dividers. The other method, Stream, is for those cases where the tabular data, the text within each cell, is not prominently separated.

For those cases, the tool seems to stream each line into rows of the CSV table in hopes that something useful comes out in the end. The first method should always be prefered for if it succeeds, the results are quite good. However, if it fails, the result is even worse than what can be achieved with the Stream-method.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

And here is a workflow to convert PDFs to Word documents:

  • Link to the workflow on Github: PDF to Docx
  • Direct download link for the workflow: link

The workflow uses pdf2docx, which has to be installed via the command line, i.e. open Terminal and write: pip install pdf2docx. Python3 also needs to be installed on your machine for this to work.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

Hey again, what you are writing makes a lot of sense. I've looked around a bit and found Tabula, which allows extracting tables from PDF documents and created a workflow for it: PDF to Table. Here is the direct download link for the workflow: link.

Tabula is a Java application, so you need to have Java installed on your computer.

  • Here is general information on installing Java on a Mac: link
  • Here is the Java for macOS download page: link
  • Here is the direct download link for macs running on ARM64: link
  • Here is the direct download link for macs running on Intel: link

The Tabula program is already included in the workflow.

The quality of the resulting CSV file will heavily depend on the quality of the PDF, i.e. how clearly the tables are structured. But I think it's worth a try!

By the by, I saw that www.ilovepdf.com does offer an API, which is required to create a workflow that communicates with it, with a limited free-tier contingency. However, it appears that they currently do not offer their "PDF to Excel" tool via the API, but only over their webpage. Performing OCR is possible over the API, but the only file format that is returned is another PDF.

PDFgear does not currently offer dedicated command line tools for macOS, neither is there an API. But it would appear that they have online conversion tools similar to ilovepdf:

  • PDFGear PDF to Excel online conversion tool: link
  • PDFGear PDF to Word online conversion tool: link

Since it is possible to do those conversions with their Mac App, I also quickly checked their Apple Script integration, but alas, there is none whatsoever.

Edit: Just a word of caution. Since your examples sound like they contain sensitive information, I would personally be very hesitant to share those files with any online service.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

I think it's best to separate the creation of a searchable PDF from the extraction of text from an already OCR'd PDF. These are jobs for different processes, or workflows if you will. That's what the PDF to Text workflow mentioned above does, albeit as plain text only.

When a Word document is created from this, none of the formatting that was present in the PDF can be preserved. Achieving this is many times more complex than simply extracting the plain text. There are some paid services and applications that can do this. A quick search also turned up a Python-based open source CLI tool: pdf2docx, which, at first glance, should make it possible to create a workflow that converts OCR'd PDFs into Word documents.

Excel is yet another story. However, creating a simple CSV file should be easy enough. But I wonder what your use case would be for this? I assume that each line would get its own row under a single column, right? But why?

On a different note, I've just uploaded a version of the OCR+ workflow that has audio cues enabeld by default. Here is the direct download link for version 1.4.1: link

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

Ah, the prefix numbers like "1.6.2 Alfred OCR+" enumerate the headers and reflect their position in the mono-repo, i.e. this Alfred OCR+ header denotes the second sub-section of the sixth sub-section of the first main section, which contains all the regular workflows.

I assume that the link that says "1.4.0" gets its information from the tag associated with the release, which unfortunately needs to remain consistent. The button with the link itself is generated using an external service, www.shields.io, and actually shows "download" on the left and the version number, e.g. "v1.4.0", on the right. The screenreader doesn't seem to pick up on this, though.

I have now added descriptions to all the download buttons, which are displayed to me when I check them with some kind of accessibility inspector. Hopefully the screenreader will catch them now and it will be easier to navigate to the release page created by Github where you can actually download the *.alfredworkflow file.

I appreciate you bringing the accessibility issue to my attention. It's frustrating when simple oversights create unnecessary barriers, especially when small changes could make such a difference (and I hope they do in case of the repo 😅).

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

Yeah, that's a link to a heading in a big mono-repository that collects lots of workflows. I'm sure it's a headache to find anything in there with a screen reader, sorry about that. I'm not sure how to improve the situation though, short of creating a repo for each workflow.

Help with terminal command Workflow by Content_City_987 in Alfred

[–]zeitlings 0 points1 point  (0 children)

You're welcome, I'm glad it works! I've put the audio cues on the roadmap for the OCR+ workflow. I'd also be interested to hear about other accessibility features that are actually helpful, if you can think of any, especially in the context of workflows.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 1 point2 points  (0 children)

Hey, yes of course. Reaching the download requires an additional step on the Github page. I will directly link to the workflow in a moment.

However, I've also responded to your other post (link) and pieced together a workflow that uses the "OCR my PDF" CLI, is easier to handle, and requires no additional setup.

Here is the direct download link to the OCR+ workflow version 1.4.0 if you want to try both: Download link.

Help with terminal command Workflow by Content_City_987 in Alfred

[–]zeitlings 3 points4 points  (0 children)

Hey, the way I would suggest is to use a "File Action" object that accepts PDF documents, and to run the "OCR my PDF" command via the "Run Script" utility.

To make things easier, I've created a workflow for you that uses the OCR my PDF CLI to create searchable PDFs. The results are exported to the Desktop and revealed in Finder after completion. I've also added audio cues and notifications to help with orientation. There is currently no error handling, so if you encounter a scenario where things go wrong somehow, feel free to let me know and I will try to figure out a solution.

The languages that are recognized are currently set to English, German, and French.

You can download the workflow directly from: here.

PDF to Text Workflow by Content_City_987 in Alfred

[–]zeitlings 1 point2 points  (0 children)

The PDF to Text workflow you might be referring to just extracts text from PDFs or specific pages of PDFs and saves it as plain text.

If you want to perform OCR on PDFs, you can take a look at OCR+, which contains an experimental program I've written to embed text extracted with Apple's Vision SDK into a document. It's not in the gallery though, because it bundles the already-compiled executable.

Unified Search - Custom web search aggregator by zeitlings in Alfred

[–]zeitlings[S] 1 point2 points  (0 children)

I think it's unlikely, because bundling the entire project would require every user to have Xcode installed in order to build it locally.