macOS Ventura: finder's file preview less powerful?

Dear community,


is it true that the recent update has decreased coverage of finder's file preview function (hit space bar in finder on any file)? For instance, I noticed this behaviour for ".tex" files - see attached screenshot.


This would really be a shame since this was an amazing feature. Any ideas?


Best,

Seb


MacBook Pro 13″, macOS 13.0

Posted on Oct 31, 2022 7:50 AM

Reply
Question marked as Top-ranking reply

Posted on Nov 13, 2022 8:12 AM

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.

Similar questions

51 replies
Question marked as Top-ranking reply

Nov 13, 2022 8:12 AM in response to a.jaffe

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.

Dec 13, 2022 3:02 PM in response to etresoft

I haven't reposted to this thread in a while because, as etresoft hinted, I had nothing productive to say. But thanks to etresoft's acerbic comments, I understand that the common problem of us TeX users has no good fix in Ventura. And no, I'm not a developer, I'm an end-user of TeX and Latex since 1986, and greatly appreciate code editors that use plain ascii (or unicode, nowadays), hence my mention of md files. The kludge I originally suggested, of briefly changing *.tex to *.text (and back again), seems to be the best one can do. There was an early helpful comment by Barney-15E who linked to Apple's Quicklook description, where we read: "Note: The list of supported common file types may change between operating system releases". So, that's that; sorry.

Dec 14, 2022 8:42 AM in response to a.jaffe

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

Nov 5, 2022 11:03 PM in response to hildebrands5

The discussion on this thread seems to be missing the point. A *.tex file is just an ordinary text file (plain ASCII, as we used to say),

and it can be read with any text editor or code editor: BBEdit, TextMate, Alpha, even TextEdit, as well as typesetting programs like TeXStudio to TeXShop. The problem is that Ventura no longer assigns text-file status to the *.tex extension, so QuickLook gets confused. A quick-and-dirty workaround is the append one letter to the extension, making it a *.text file, and the QuickLook preview appears at once; but then one needs to change back to *.tex so that the code editors know what to do with the file contents. Even more alarming is that Markdown files, with an *.md extension, cannot be read by QuickLook either. This is clearly an operating system problem: what is needed is to put back *.tex and *.md (and *.bbl, while we're at it) to the list of recognized text-file extensions. Any chance of that?

Nov 6, 2022 1:53 PM in response to VikingOSX

VikingOSX wrote:

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.

Those old QuickLook previews have been deprecated two times over now, maybe three. It has been several years since Apple stopped supporting the stand-alone plugins that you could just drop in the QuickLook folder. Then, Apple published a new QuickLook generator template a few years ago, but kept supporting the old format. Of course, no 3rd party developers, including myself, updated to the new format. So then, Apple tightened the screws. Xcode would crash if you built a release version of an app that included an old QuickLook plugin, but only on the 2nd attempt. That was quite annoying for a couple of years and I finally ripped out the QuickLook plugin altogether. The new architecture works well enough, but I haven't bothered to add a new QuickLook back into EtreCheck due to concerns about backwards compatibility for people still running 10.13.


If Apple has completely stopped running the old QuickLook format, that would explain why they dropped support for old formats like PS and EPS.

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.

Those new QuickLook generators are easy enough to build. They do have to be bundled into an app. Just write a super-simple document-based app that can open Tex files. Then use the same logic in the QuickLook generator. For someone who can build a Mac app and cares about Tex support, it should only take a couple of hours.

Dec 14, 2022 1:51 AM in response to a.jaffe

Ok, I believe that I have solved the problem slightly more generally.


Having noticed different behaviour after deleting the [syntax highlighter](https://github.com/sbarex/SourceCodeSyntaxHighlight) app, I tried some more deletions. 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)!


But I still wanted TextMate, so I reinstalled it (and TeXShop, although I really don't use it) and... it still worked! It still had "Open with BBedit" but I was able to change that with the "Get Info" dialog. It's not perfect: no syntax highlighting, and css files still don't show a preview, but it's an adequate solution (though I may actually go back to the new syntax-highlight app).


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....



Dec 14, 2022 9:14 AM in response to etresoft

etresoft wrote:

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.

And the exercise was every bit as fun as I had imagined. First of all, I downloaded the version for "Sierra and above". Of course, it requires Mojave. No problem, I've got lots of VMs. I did get it working in Mojave.


And guess what? These tools never, ever provided a functional QuickLook display. One of them, the "BibTex" tool did provide syntax highlighting. But the other one just displayed the source. Or perhaps it was simply always broken. When I deleted both quicklook extensions from the apps, it still worked.


To summarize, this problem was always caused by buggy 3rd party apps. These apps have always been buggy. It's just that no one noticed until Apple changed the QuickLook architecture and one of those buggy apps triggered some other unexpected and unexplained behaviour.


The the poor LaTeX users have never had a functional QuickLook preview that displayed the rendered content. That's literally what QuickLook was designed to do. It should come as no surprise that someone who didn't understand the fundamental concept would develop a buggy implementation.

Nov 6, 2022 9:51 AM in response to hildebrands5

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.

Dec 13, 2022 6:05 PM in response to Pipe_luque

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

Then you need to install an app that can handle .Tex and provides a quick look rendering plugin (or whatever it is called). I found BBEdit does provide Quick Look with the needed information to display the markup. I believe I stated this on the first page of this post, and it is marked as the most correct answer.


You don’t seem to understand why it no longer works, and seem unwilling to accept the reason.

Nov 24, 2022 8:17 AM in response to Pipe_luque

Pipe_luque wrote:

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

Let's set expectations then. You aren't here to substantively contribute anything to the question at hand. You are only here to attack me personally. Gotcha!

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

First of all, the technology in question here is "QuickLook", not "QuickView".


Secondly, what you are referring to is a fallback display. Long before QuickLook even existed, the only way to display an icon for an app's document type was using a hard-coded icon defined in the app's resources. That document icon is still there and is sometimes used when a custom document type has no QuickLook generator or when a QuickLook preview would make no sense for a given document type. It can also appear when the QuickLook preview generation fails for whatever reason. One good reason would be a corrupt or empty file.

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

I'm confident that I've objectively demonstrated my knowledge of how QuickLook has developed over the years and how it works today. Furthermore, I'm confident that I have fully described not only the cause of this problem, but even it's ultimate solution. What more do you want?


Are you demanding that I develop TeX QuickLook preview that functions properly on Ventura just for the use of a handful of people still stuck in 1988? I actually did that for EPS files because I just happen to have a bunch of EPS files from 1988. I considered writing something more extensive for PS files when Apple removed support for PS and EPS in Preview, but several of the example Ghostscript files wouldn't render, so I didn't want to deal with that. To be clear though, I did write the app. It's just for me only. 😄


If the developers of your existing TeX apps are unwilling to update their apps to work property with Ventura, I would certainly consider publishing a TeX preview app. I could even write a full-fledged editing suite if you want. But you would have to pay for it. And since it is such a tiny, tiny market, you would have to pay for the entire development up front. Maybe try a GoFundMe with other people in a similar predicament? I'll even make it open source if you want. I think I'd probably have to. Just so you know, it won't be cheap.

Dec 13, 2022 6:37 PM in response to Pipe_luque

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.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

macOS Ventura: finder's file preview less powerful?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.