macOS Ventura: finder's file preview less powerful?

a.jaffe wrote:

I am seeing the same behaviour. (See also here.)

I think there is some confusion in this thread about preview vs quicklook.

Preview and QuickLook are the same thing. I can understand how people who haven't dealt with these technologies might be confused. It is extremely confusing.

There are two parts to QuickLook: icon thumbnails and previews

What you (and the Finder) call a "preview" (Finder > View > Show Preview) is actually the icon thumbnail.

What you (and the Finder) call a "quicklook" (Finder > {select file} > {press spacebar}) is the preview

This difference is important because, internally, a quicklook plugin can choose to implement only one of these features. For example, in my own app, I implement the preview to show an EtreCheck report in a Window. But the report is just a wall of text. I don't implement the thumbnail icon. In this specific example, only the full-size preview has any meaning. A TeX file is very similar in concept. I expect anyone who has written a QuickLook plugin for a TeX file would make a similar decision. You just can't represent a 12 page paper full of math equations in a single icon. But you can do it in a scrolling preview.

But wait, we aren't done yet. It is even more complicated.

As of macOS 10.13, Apple started rolling out a new Quicklook architecture. As I discovered just the other day, Apple didn't actually finish this rollout until Ventura. For each of those types of previews, there are two ways of implementing them - a complicated way and an easier, but perhaps more complicated, way. This is true of both the old and new versions. In the "new and improved" version, only the view-based, "complicated" way is supported. The easy method is not supported until macOS 12. Alas, that method doesn't actually work properly until Ventura.

So that is potentially 8 different ways of drawing a preview, in potentially 5 different contexts (which I didn't mention), all behaving differently over 8 different operating systems. Confused yet?

PS: I'm not sure how much the old "qlmanage" tool even works anymore. The new method is, of course, more complicated. Use the following command to dump all quicklook information:

pluginkit -mvvvv -p com.apple.quicklook.preview --raw

Use this command to see information about a specific UTI - not, not that UTI, I mean the problematic one - a Uniform Type Identifier. (It would sure be nice if some antibiotics and cranberry juice could clear up this mess.)

pluginkit -mvvvv -p com.apple.quicklook.preview -i com.etresoft.EPSView.EPSViewQuickLook --raw

Note that the -i <identifier> flag identifies the bundle identifier of the quicklook plugin inside an app's bundle. This example is using my EPSView tool that I wrote when Monterey removed quicklook previews from EPS files. (Ventura removed support for all EPS and Postscript files in Preview (the app) but not the lower-level APIs. Did I mention that this stuff was confusing?) This command is useful to identifying what an individual plugin is doing. I don't know any method for identifying which plugin should be used, or could be used, other than manually searching the output of the previous command.

Preview is working fine for TeX/LaTeX files -- it is quicklook

that has stopped working correctly. Indeed, pressing the spacebar on a *.tex file show the correct preview icon but the message

The extension com.apple.tips.TipsAppQuicklook-macOS does not implement file previews

I think that message is a side effect of the TextMate app. My explanation above on the details of how all this works is woefully incomplete. I didn't mention how individual apps can import and export UTI->extension->MIME type mappings. I'm guessing that TextMate exported a UTI that matched the TeX files and made it a child of the "public.text" UTI (which is appropriate). However, since TextMate didn't have the appropriate plugins, the operating system is now a bit confused.

Any more nuanced ideas?

You want me to get more nuanced? Sorry, but here is a 5000 character limit on replies in the Apple Support Community and I'm already over 4000.

You just need apps that have better support for TeX files. That file format was ancient when I was in grad school back in the 1990s. The output from those tools is horribly ugly. I tried to replicate what you are seeing. I actually couldn't get any quicklook or preview to work, but I did reproduce that strange "tips" message. You must have more TeX apps than I could find. Texstudio is ancient and isn't even signed. It doesn't even work without another 5 GB (!) download of MacTex. I was prescient enough to save my /usr/local directory before MacTex trashed it.

I will agree that Apple has made this unbelievably difficult. I'm not exaggerating when I say I've really skimmed the issue here. You will need to contact the developer(s) of your favourite LaTeX tools and ask them to write a new-style QuickLook preview for their apps.

Whatever you use to create/edit .TEX files needs to provide a Quick Look importer to show the preview.

It could be that the importer bundled with the app needs an update to work with Ventura, but I don't know if there were any changes in that framework.

Apple Developer Documentation

I am seeing the same behaviour. (See also here.)

I think there is some confusion in this thread about preview vs quicklook.

Preview is working fine for TeX/LaTeX files -- it is quicklook that has stopped working correctly. Indeed, pressing the spacebar on a *.tex file show the correct preview icon but the message

The extension com.apple.tips.TipsAppQuicklook-macOS does not implement file previews

Most of my other text file types (*.c, *.py, *.text, etc) seem to work fine, and give an appropriate "Open in some app" button, but *.tex fails as for the OP (my upper right button says "Open with Textmate". (See also this thread which sees similar behaviour for css.)

(Even if this is due to deprecated ql generators, it's still weird that it tries to default to the "tips" app!)

I think that this used to be handled by TextMate (with syntax highlighting!), but I am not sure. But I have plenty of other TeX-capable editors, so I am surprised by this behaviour. And TextMate does still work as the quicklook generator in at least some cases.

Any more nuanced ideas? (E.g., I have a lot of *.tex-capable editors on my system, some of which do supply QL generators. Is there any way to force one of them to take over?)

It's hard to say. It is certainly a complicated system. It is actually harder to test than to implement. And yet, it really isn't worth the effort. No one ever comments on or appreciates the fact that certain developers add these kinds of functionality. If it breaks, nobody mentions it. It is always the same thing, everybody blaming Apple for removing some feature that they publicly deprecated 9 years ago. How many of those people ever contact the developer? Judging from this thread, and my own personal experience, not a one.

I don't know what's going on with the 13.1 beta. It is against the Apple Support Community Terms of Use to discuss beta products. Maybe 13.1 "fixes" the problem by breaking it again, and showing the fallback document icon. Or maybe it is modified to show the fallback document icon for files less than 20 bytes or something.

I just don't get this obsession to always have the latest version. Monterey has been working great for me since I installed it a few months ago. My Ventura testing is going well too. It is an obsession, isn't it? Same cycle every year. Everyone has to have the latest drug. Then they howl when something goes wrong, always hoping that the next update will provide the needed fix. Sounds like addiction to me. It even uses the same terminology, i.e. "a fix".

a.jaffe wrote:

So, I don’t think the “Open with BBEdit” button means that BBEdit is actually the provider of the appropriate quicklook extension — the BBEdit developers have explicitly told me that they don’t provide one!

You can always look inside the app bundle to see if it includes a QuickLook extension. Old-style QuickLook generators are found in the app bundle Library folder inside the QuickLook folder. Modern QuickLook extensions are in the Plugins folder but may not be clearly identified as such. If there are modern QuickLook extensions, they will be listed in System Settings > Privacy & Security > Extensions > QuickLook.

The "Open with" button may have nothing to do with the QuickLook extension, other than being displayed in the window. It merely indicates what app is set as the default app with which to open the document. If said app has a valid QuickLook extension, then it will be used. If not, then some other (see below) mechanism may be triggered.

And, for what it’s worth, I’ve had BBEdit installed the whole time I was having the “TipsAppQuicklook” problem with *.tex files.

That is because the problem was always caused by various ancient and unsupported open source 3rd party apps.

All BBEdit does is add the "tex" and "latex" file extensions and associate them with the "com.barebones.bbedit.tex-source" UTI and define said UTI as conforming to the "public.source-code" UTI, which the operating system already handles natively.

But then those broken apps corrupt the UTI and QuickLook databases and break it all.

As mentioned above, the app at https://github.com/sbarex/SourceCodeSyntaxHighlight seems to fix it for me by explicitly providing quicklook for many types of text source files (perhaps too many!)… Also, after installing it and then uninstalling it as a test, the “TipsAppQuicklook” message seems to go away for some — but not all! — file types, but still without actually showing the preview window.

...

Curiouser etc.

Indeed. I'm going to fire up the High Sierra VM and see if I can get those old apps working. I just want to see if they ever displayed the QuickLook preview correctly. Based on what you've said, I strongly suspect that it never worked.

First, I deleted TextMate. Still no preview, but the button changed from "Open with TextMate" to "Open with TeXShop". So I deleted TeXShop. And then... it worked (i.e., unhighlighted full window preview with an "Open with Bbedit" button)!

Deleting buggy 3rd party apps often fixes these problems.

Clearly there is some dependence of all of this on the order of installation of the applications and how they register their capabilities which can result in clashes. I wonder if it's documented anywhere and if there are less sledgehammery ways to change how it works....

Indeed it is documented. Apple says, "When Quick Look searches for a generator to use, it first looks for it in the bundle of the associated application and then in the standard file-system locations in the order given in the list above. If two generators have the same UTI, Quick Look uses the first one it finds in this search order. If two generators claim the same UTI at the same level (for example, in /Library/QuickLook), there is no way to determine which one of them will be chosen."

Two things to note:

1) You'll have to launch the app first to have it registered with the system. So the first time you run TeXShop or any of the associated apps, it might all break

2) All of this was deprecated years ago. Ventura uses a completely separate architecture from iOS. Some of the old bits might still work, and some of the old bits just might cause strange bugs like the ones you are seeing.

Just a further quick update: the quicklook behaviour seems to be brittle: if I open a *.tex file with TextMate it (sometimes?) reverts to the buggy "Tips" message with no preview window. Hmmmm.

See #2 above

hildebrands5 wrote:

I don't understand what you mean. It obviously does NOT work on my machine. Before the update, I saw the raw text that is contained in a *.tex file, now I see this weird Tips app stuff. At the same time, it works on other peoples' machines. So, what do you mean by "every screenshot in this thread shows it working properly"? The same is true for *.md files.

Oh boy! You're in trouble now! I'm not on the iPad anymore and I can more easily take screenshots and mark them up.

Same with BBEdit...

There simply isn't anything to display in a 12 or 14 byte file. What's it supposed to show? Here is the smallest possible HTML file:

<html></html>

That's 13 bytes. One of your files was smaller than this. A preview of nothing is, in fact, nothing.

I don't know what you mean about "weird Tips app stuff". You're going to have to explain that in more detail.

At the same time, it works on other peoples' machines.

OK. What does that mean? Can you take a screenshot of the same file showing one kind of preview on someone else's machine and an invalid preview on your machine? So far, all you've shown are perfectly valid previews of virtually empty files.

Also, no idea how your opinion about markdown matters for this. If you have something productive to say, I'd highly appreciate it.

That was a reply to jvarilly. It is common for people in these forums to add "me too" replies. In most cases, their "me too" replies have nothing to do with the OP's (your) problem. We just have to try to politely tell these people to go away and ask their own question. (They usually don't appreciate that suggestion.)

In jvarilly's defence, that was an on-topic "me too" reply. While it was "on-topic", it wasn't actually valid or helpful. jvarilly's comment about Markdown suggests that they were possibly a developer. Being a developer myself, I would really appreciate having a Markdown QuickLook preview app. But I don't want it enough to bother writing it myself. And more importantly, there's absolutely no money in writing QuickLook previews so I'm not going to write it for anyone else either.

When macOS Monterey was introduced, Apple removed the QuickLook previews for EPS files. I did write a quick-n-dirty app to restore those previews and gave that app away for free. (Alas, the rules of the forum forbid me from posting a link to it.) In Ventura, Apple removed all ability for Preview to open Postscript or EPS files entirely. Again, I wrote a quick-n-dirty app to open and preview these files. But Postscript is a much more difficult format and that's a can-o-worms I didn't want to bother dealing with in a free app. And as before, there is absolutely zero money to be made in the opening-40-year-old-file-format market. So now that little app is just for me only.

Is that productive? Who's to judge? I don't have any tex files and I'm not going to make any. Back in grad school, all the hip students and professors used LaTex for their papers. I was never hip. I used equation editor in Word. As you might expect, that, too, was not appreciated. How dare I just type in the equations without learning a new typesetting language. The Horror!

On macOS Monterey and prior, I had a third-party QLMarkdown Quick Look extension stashed in my ~/Library/QuickLook folder and that addition showed me the content of the .tex files, or even XML structure. That third-party QLMarkdown tool quit working on Ventura and my .tex files now display the image of the .tex content in the displayed icon.

This is as good as it is going to get, as Apple does not support LaTeX/TeX source markup in Quick Look. I may be obtaining this view because I have the full MacTeX 2022 installation and it does provide some qlgenerators of its own. For the above QuickLook view, my default opening application was set to MacVim 9, but the same occurs with Sublime Text 4, TeXShop 5.0.3, or the current BBEdit. 14.6.1.

I came to this discussion trying to find an answer/solution to the lack of quick view for .tex files which I used on a daily basis before upgrading to Ventura. And I have to say I am genuinely confused as to why you're taking part in this discussion. You've not really provided anything I would consider to be helpful (this is based on my own opinion and lack of technical understanding to your longer replies, so I might be completely wrong), and you've made clear your disdain for TeX in general (even though a vast portion of the scientific community would strongly disagree with you):

That file format was ancient when I was in grad school back in the 1990s. The output from those tools is horribly ugly.

so I'm not sure what your gaining from being here.

But all that is besides the point, I just wanted to point out something you said I believe to be wrong:

here simply isn't anything to display in a 12 or 14 byte file. What's it supposed to show? Here is the smallest possible HTML file:

<html></html>

That's 13 bytes. One of your files was smaller than this. A preview of nothing is, in fact, nothing.

A preview/quickview of a file with nothing is not, in fact, nothing, it is a file with nothing in it. See for example this completely empty file (0 bytes, so even shorter than a sentence!):

and when I press the space bar I get the following quickview

Also, as others have pointed out a .tex file is just a plain ASCII file, which before Ventura had a working quickview like any other text file. So when you say this:

There is no problem. Ventura works the same was as all previous versions. Every screenshot in this thread shows it working properly.

especially given your lack of knowledge of how TeX files behaved in previous versions of macOS, you're 100% wrong.

etresoft wrote:

That's what's so confusing. You, and everybody else in this thread, wants exactly what Ventura does and every version of macOS has always done.

Except Ventura does not do it, which is what everyone has been trying to tell you, but you keep telling people they are wrong, and being aggressive in your replies. I cannot directly prove that it used to work before Ventura, since I only have a Ventura machine, but I can show you an example of the behaviour we were used to and how this has changed since Ventura.

This is an example of how it worked before Ventura (since my machine has Ventura installed I achieved this by temporarily changing the extension of the file from .tex to .txt, but this is the way it used to work with .tex files before Ventura):

and this is the behaviour we are now seeing in Ventura:

So you are right that it used to work in previous version of macOS, but it clearly does not work anymore in Ventura.

So what am I missing here?

Yes. I know. I'm missing syntax highlighting. But then, your extension-swapping example doesn't have syntax highlighting either.

Your TeXShop app doesn't support QuickLook Previews at all. It doesn't even support TeX. The first thing it does when you try to render is demand that you download some other 5 GB download. That other download then installs an older version of TexShop. But it doesn't matter, TeXShop never supported QuickLook Previews. It was some random set of utilities included in that 5 GB download that was giving you those previews before. Since those apps haven't been updated in 10-15 years, they don't work anymore. So what you see is some generic fallback display.

Did Ventura break this? Well, technically, yes, it did. But why are you installing Ventura to run 15 year-old software? If Ventura didn't bring any changes, any new features, or any security fixes, then what's the point of running it? You want a new operating system that has all those new fixes, but you want it to run unchanged from the previous version? That's simply not going to happen. All of these old Mac interfaces are deprecated. All new code is iOS code ported to the Mac. It is the responsibility of 3rd party developers to adopt these new APIs.

Your example shows a file with a size of 0KB which may be the problem. I've never used .tex files before so I'm not sure how macOS handles those files normally. In order for the Quicklook feature to work, then the file type must be something macOS recognizes. Even with a recognized file type, sometimes the file configuration will be in an unrecognized format (perhaps utilizing newer features that macOS is unable to handle natively).

I'm not sure whether Quicklook is able to utilize any third party apps when performing the document preview, but if it does, then perhaps that third party software is not fully compatible with Ventura.

Get Info on that TeX file and see what app is set to open it.

It appears that the Tips app is trying to open it, thus it is trying to create the preview. It can't.

By not interpret the markup, I mean I see the markup. Not the rendered file.