Would somebody using OSX have a look? Thanks!

Hi all,
I can not confirm on Mac OSX 10.6.6. If I press the space bar on any ODF document apart from a database document (which is a special case, so I didn't expect that to work), I get a preview of the contents of the file.


So this works for me.

Alex

setting NEEDINFO keyword

One thing it doesn't do, is enable you to flick through the pages of a multi-page ODF document, but then Quicklook doesn't let you do that with Word documents either (at least not on my system).


Alex

Created attachment 44548 [details]
output of qlmanage -m plugins

The /System/Library/QuickLook directory does not show the odt plugin, nor does it appear on an inquiry of the plugin db.

@Alex

This OSX 10.6.6 system had LO 3.3 installed after OOo had been installed and is currently running:

LibreOffice 3.3.1 
OOO330m19 (Build:8)
tag libreoffice-3.3.1.2

Neither icon view nor space bar from any other Finder view generates a thumbnail; one only gets the new LO standard doc icons, which changed with the LO install and upgrade.

restarting finder has not resolved the problem, not has qlmanage -r

Can you compare your qlmanage output and contents of your /System/Library/QUickLook directory?

(In reply to comment #6)
> @Alex
> 
> This OSX 10.6.6 system had LO 3.3 installed after OOo had been installed and is
> currently running:
> 
> LibreOffice 3.3.1 
> OOO330m19 (Build:8)
> tag libreoffice-3.3.1.2
> 
> Neither icon view nor space bar from any other Finder view generates a
> thumbnail; one only gets the new LO standard doc icons, which changed with the
> LO install and upgrade.
> 
> restarting finder has not resolved the problem, not has qlmanage -r
> 
> Can you compare your qlmanage output and contents of your
> /System/Library/QUickLook directory?

Or, maybe to be more accurate,  maybe it looks like the qlmanager is pointing to the MSO plugin, instead of two an LO plugin?  Where should the LO plugin be, and did the qlmanager resort to the MSO plugin because it couldn;t find the LO plugin?  Because this system originally had MSO installed, then OOo installed, then LO installed, I did have to manually change the default apps for all the various files types....   But,  if the plugin is on the system,  one shuld be able to reset....

Hi Marc,

By the looks of it, it works here on my system because I have NeoOffice installed:

qlmanage -m plugins | grep oasis
  org.oasis.opendocument.text-master -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.text -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.formula -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis.opendocument.graphics -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.graphics -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis.opendocument.formula -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis.opendocument.spreadsheet -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.spreadsheet -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis.opendocument.text -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.text-master -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis-open.opendocument.presentation -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)
  org.oasis.opendocument.presentation -> /Applications/NeoOffice.app/Contents/Library/QuickLook/neopeek.qlgenerator (1.0.1)

So yes, if you only have LibO or OOo then apparently the plugin is not present...


Alex

@Alex - So,  the question is, does LO include a plugin, and if so, where is it? My guess here is that either there is no plugin, which is strange because as I note below I believe there is a plugin for OOo (or at least was one in some beta) or that it is hidden somewhere and that there is an installation problem vis-a-vis invoking qlmanager.

If there is no plugin, is it because of a problem in moving from OOo, or is OOo plugin-less (again see note about OOo below) as well. 

And, if the underlying issue is that neither OOo nor LO have a plugin,
then what needs to happen to resolve this issue,  supply a plugin, and roll it into LO.

I also noticed this in the NeoOffice wiki:
http://neowiki.neooffice.org/index.php/Snow_Leopard_Upgrade_Issues  which
suggests that SnowLeopard caused the NeoOffice plugin to fail with NeoOffice, 
though it apparently is working for you in LO-lol. The NeoOffice wiki has a stub for NeoPeek, but contains no info.

OOoforum has this thread: http://www.oooforum.org/forum/viewtopic.phtml?t=64452 which indicates OOo should have something, and perhaps more importantly, there is this from  Eric, who as I recall was heavily involved in the OOo
porting:  http://eric.bachard.free.fr/news/2008/03/quicklook-on-leopard.html 
which points to a beta quicklook plugin back in 2008. Is Eric involved with LO? I tested the beta file that Eric posted and it gives the doc shape, but fonts must be an issue because all you see are block forms instead of letters. I could find nothing more on the plugin since 2008.

@Alex, could you post the neopeek file here? I don't want to have to download all neooffice to just get the generator file to test.

Also I found an additional comment at openoffice which suggests that the OOo plugin was simply never rolled into the the product.

Hi Marc,
(In reply to comment #10)
> @Alex - So,  the question is, does LO include a plugin, and if so, where is it?
> My guess here is that either there is no plugin, which is strange because as I
> note below I believe there is a plugin for OOo (or at least was one in some
> beta) or that it is hidden somewhere and that there is an installation problem
> vis-a-vis invoking qlmanager.


I too, seem to recall that there was a ql plugin at one time for OOo, but I have no idea what happened to it.


> 
> And, if the underlying issue is that neither OOo nor LO have a plugin,
> then what needs to happen to resolve this issue,  supply a plugin, and roll it
> into LO.

I quickly checked through my git repo and couldn't find any thing in the LibO source code. I also guess that it is not around in the OOo source either, otherwise it probably would have found its way into the LibO source too (he says hopefully).


> 
> I also noticed this in the NeoOffice wiki:
> http://neowiki.neooffice.org/index.php/Snow_Leopard_Upgrade_Issues  which
> suggests that SnowLeopard caused the NeoOffice plugin to fail with NeoOffice, 
> though it apparently is working for you in LO-lol. The NeoOffice wiki has a
> stub for NeoPeek, but contains no info.

Hmm, well I might have to go and contradict that then ;-)


> 
> OOoforum has this thread: http://www.oooforum.org/forum/viewtopic.phtml?t=64452
> which indicates OOo should have something, and perhaps more importantly, there
> is this from  Eric, who as I recall was heavily involved in the OOo
> porting:  http://eric.bachard.free.fr/news/2008/03/quicklook-on-leopard.html 
> which points to a beta quicklook plugin back in 2008. Is Eric involved with LO?

No, if you mean Eric Bachard, he has stayed with OOo, but is also doing his own thing with EducOOo. There is a certain amount of past "history" between Eric B and other developers / members of LibOn (and NeoOffice for that matter), that led to this situation as so often occurs in free software development projects. Suffice it to say that I doubt at the present time he would be willing to help out directly, but obviously I can not speak in his stead, I am just basing my assumptions on his past and current exchanges on the various OOo lists of which I am still a member.

Yes, I guess the main problem is finding where the code is at the moment.


Alex

@Alex,

DOn;t know if you saw my note in the cross-traffic,  but as it is open code, could you post the NeoPeek glgenerator file here so I can compare its funtion with the beta that Ericb posted in 2008?

I do recall ll kinds of gnashing of teeth back then....  I had been promoting using OOo with OSX under X11 in public schools, and in the space of a few monhs (though it was likely more like a few years lol) there was conflict over NeoOffice and an Aqua version of OOo - reminded me of the split over phpgroupware - unfortunate when such schisms potentially dilute energies really needed to focus on one product. Now we have the same situation as the future of OOo hangs over LO's head, so to speak.  I switched because I had hoped that this was NOT going to be a fork.....  now I am not so sure ;-)

Hi Marc,

I can't upload neopeek.qlgenerator because it is an app bundle, and freedesktop refuses to take it. The bundle contains :

Contents (folder)
Info.plist
 |----->MacOS (folder)
   |------->neopeek (binary)
 |----->Resources (folder)
   |------->English.lproj (folder)
       |------------>InfoPlist.strings


I can try and post the binary (assuming freedesktop lets me), but its probably not much good to you without the rest.

Alex

@Alex,

As I understand quicklook, it is looking for a glgen file, so if NeoPeek is providing the service in some other fashion, how is it working, and how is it associated with the pertinent files.  It would seem that the OS would have to know when and how to invoke neopeek (assuming that neopeek is only invoked for files associated with it, then it wouldn't need to be passed that info.

So,  if NeoPeek is available under the appropriate license and it can be implemented for LO, that wold seem to be a first step to resolving the situation pending creation of LO glgen files,  though if neopeek is doing this in some other fashion, maybe the way it is functioning is to be preferred?

How big is the bundle? Shouldn't you be able to zip the app bundle to upload?

Created attachment 44711 [details]
neopeek ql generator

This was downloaded from :

http://trinity.neooffice.org/downloads/neopeek.qlgenerator.tgz


Alex

In the OOo code, the quicklookplugin01 CWS is/was supposed to be integrated into OOo version 3.4.


Alex

@Alex,
I compared the OOo beta and the neopeek file.  The OOo allows much more control over the thumbnail (it is zoomable) with the major issue being the lack of a font,while with the neopeek plugin I cannot zoom and cannot make out any text, so even if it does do fonts it can't be made out. IS that the same behavior you are seeing?  If so,  then the issue for us is the font usage.  Did you find where any work had been done on the plugin since 2008? There was a bit of a discontinuity in trying to track things (perhaps due to recent transition) but I could not find any recent QA on it at OOo.  If there is a note that it met QA for 3.4, there should be something more than the beta code that Eric published 3 years ago.

Created attachment 44714 [details]
The  OOoQuickLookqlgenerator beta file posted by ericb here http://eric.bachard.free.fr/news/2008/03/quicklook-on-leopard.html

@Alex,
Have you found an actual build of the file that is targeted for OOo3.4?

Hi Marc,

Yes I can confirm the behaviour of the Neopeek plugin. The preview remains thumbnail size and can not be expanded, even in full screen mode, so it is not possible to actually read what is in the file.


As for actual code, I've been looking hard, but still not found any...


Alex

FWIW, the code Eric is talking about is in this cws: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fquicklookplugin01 - currently no time to look into this myself, if someone could play with that & vouch for it, I'd happily include it into 3.4 (warning, feature freeze date is coming Monday)

@tbehrens  Yes,  but where in all that is a built test file.

Thanks for bugreport
Please, verify in last version of LibreOffice

ODTs in LO 3.5 on OSX 10.6 still do not appear correctly (format is there but font is not),  though ods files do. As I have tested on systems that have had previous installs of OOo or LO it is possible that this failure is an artifact, but if so,  it is an artifact that should be resolved through any installation.  To put the question back to others,  has anyone seen any resolution of this bug, and why would confirmation be required unless some change were made, and if so what cganges were made and where would we look to examine those changes?

Created attachment 59163 [details]
Image of what an odt file looks like

Using quick touch this is what I presently see viewing an odt file (ods files display correctly.)  Formatting is correct,  but the font is not.

Created attachment 59166 [details]
dump of qlmanage -m plugins

As you can see,  there is quite a bit of detritus here.  If 3.5 was supposed to resolve this bug - and the bug does not appear in new installations, then upgrading is not resolving issues from prior installs and arguably the install should address that or there should be a specific procedure identified for curing the problem.

An examining System->Library->Quicklook I find no qlgenerator for LO (what is presented will be filed as an additional image.)

Created attachment 59168 [details]
Files contained in OSX 10.6 /System/Library/QuickLook

Not sure if things have been moved about,  but here's the Library where I assume the generator should live,  if one was installed by LO 3.5,  and you will notice the presence of the old OOo generator from 2007 and the neopeek generator that is at least partially successful (provides formatted image without correct font for odt, but works for ods.)

I am happy to tweak whatever on instructions from whomever so as to test any solutions,  but I have yet to see anything for LO that purports to fix this.....

Thanks for additional testing

Your welcome,  but why did anyone need additional testing if no appropriate file is included in the distro.  I guess I am confused as to what the status is here in that it was my understanding that the problem realy resulted from the absence of the necessary file. So,  am I mistaken, and if so what is the source of the problem, and if I am not mistaken, what are the issues with including a functioning qlgenerator file?

"Version" is most old version where bug is reproducible. Not current version.
Changing to 3.3.1 back

PLEASE LEAVE IT AT THE OLDEST REPRODUCABLE VERSION - Thanks

@Marc:
Seeing you boasting here:

http://nabble.documentfoundation.org/Excuse-me-but-your-opinion-is-simply-unimportant-Start-over-and-you-can-expect-more-of-the-same-tp4001269p4001858.html

that you knew you are creating extra work for the volunteers on the QA team with intend is really disgusting given the workload of this team.

Also note that the version is clearly documented to be _first_ version showing the bug:
http://wiki.documentfoundation.org/QA-FAQ

Even if it wasnt documented: If you take a moment to think about this, there is also no other way the version field can be used: If the bug is not present in the latest release the bug is closed anyway. If the bug is present in the latest release, the bug is open and and the only relevant information is: since when?

Please refain from continuing with abusive behaviour like the one you are boasting about. I dont think repeating such behaviour is going to be tolerated.

reopen, for obvious reasons.

Neolight seems to fail to generate a preview for some .odt files but not others. I have examples of both if anyone was looking to fix it. As of at least 10.8 QuickLook can preview .odt files without a plugin. This built-in funtionallity works for all such files I have. I didn't test beyond this.

While I swore off participating here,  I was taken by the recent report by reeves_28.....
I recently moved to 10.8 and while QuickLook will pop an image (as it has since I noted in this report),  the image still does not employ a readable font.

Created attachment 70854 [details]
image of preview in 10.8 without any generator file

My experience (Mac OS X 10.8.2, LO 3.6.5.2) is that when I select a file in Finder, I get the generic (currently green) LibreOffice Calc icon in QL. If I press the space bar, I just get a bigger rendering of the same icon with an offer to open the file in LO.

$ qlmanage -m plugins | grep oasis
  org.oasis-open.opendocument.text -> /System/Library/QuickLook/Text.qlgenerator (555.4)

That looks like a Mac default (Text.qlgenerator) so nothing has been installed. I've never had NeoOffice or anything like that ever installed.

I'm coming late to the party: can I install NeoOffice's plug-in by itself? Or maybe OOo's? Or is there one (even if beta) available directly from the LO team? This isn't exactly killing me, but it would be nice to have QL working with LO.

Thanks!

Summary:
Apple support quicklook only .odt files (text files) - but it not support all features like Charts/Equations inserted in text files…
Apple NOT SUPPORT Draw (.odg), Calc (.ods), Equations (.odf) or templates. of all LO/OO files
LibreOffice.app bundle 3.6/4.0 DOES NOT CONTAIN QuickLookPlugin for OpenOffice formats.

(In reply to comment #50)
> Seems that this means that the new LO term for broken is unenhanced and the
> likelihood of getting this functionality back continues to diminish ;-)
>
The term for "not yet implemented" is enhancement. if there is suitably licensed code, and you have time at your disposal, please do go ahead and hack it into shape, and attach it here. Everything else at this point is probably not too constructive. ;)

QuickLook is a must on Mac OS X. Most filetype can be  viewed with quick look, and the absence of the open document qlgenerator is a real detuning.
http://developer.apple.com/library/mac/#documentation/UserExperience/Co
nceptual/Quicklook_Programming_Guide/Articles/QLProjectConfig.html

*** Bug 59553 has been marked as a duplicate of this bug. ***

*** Bug 36431 has been marked as a duplicate of this bug. ***

*** Bug 81589 has been marked as a duplicate of this bug. ***

REOPENED is not the correct status - setting to NEW.

Apple added support for open document files. On 10.11.1 and latest LO nightly preview is working for calc and writer. Didn't test anything else.

The original bug was about quicklook support for 10.6. This will not happen, since LO now requires 10.8 minimum.

For me the latest LO + latest OS X has the requested functionality.

Thus WORKSFORME seems appropriate. Please file new bugs, if you don't like the current behavior, so we can start with a clean slate.

QuickLook is still unsupported in LibreOffice, even on Mac OS X 10.11.

QuickLook is still unsupported in LibreOffice, even on Mac OS X 10.11.3.

REOPENED is not the right status. Moving back to UNCONFIRMED for independent confirmation that it's still an issue.

Created attachment 123217 [details]
image of odt in quicklook (LO5.1 OSX 10.11)

Demonstration that the bug is still there

In sum, under LO5.1 under OSX 10.11 ods files appear properly in quicklook, while odts do not.  Nor have I yet to see any image suggesting that odts work properly under quicklook.

I would think that the uploaded image might serve as "independent corroboration"?

In LO bundle is only "OOoSpotlightImporter.mdimporter", I cannot find anything related to QuickLook (*.qlgenerator).

Problem is following:
So *.odt (text) files are handled by system "Office.qlgenerator" or "Text.qlgenerator" (located at /System/Library/QuickLook/).

Other LO file types as *.ods (spreadsheet), *.odp (presentation), *.odg (draw) hasn't their QuickLook plugin.

Created attachment 127867 [details]
OpenDocument Text Preview: Working

Created attachment 127868 [details]
OpenDocument Template Preview: Not Working

Created attachment 127869 [details]
WordPerfect Document Preview: Not Working

Created attachment 127870 [details]
WordPerfect Template Preview: Working

Per other 3 attachment uploads, Quicklook generators in LibreOffice 5.1.4.2 on MacOS (Sierra) do not reliably render previews. OpenDocument text files preview, templates do not. Meanwhile, WordPerfect templates render, but WordPerfect documents do not.

*** Bug 96754 has been marked as a duplicate of this bug. ***

After discussion in IRC QA chan, meeks and x1sc0 concluded there's budget for 2019 to look into macOS specific wishlist items and this would be a good candidate. Said to assign Tor, so doing that. This would be a really important addition to LO on macOS as it is one of the very few apps not supporting QuickLook.

Adding IRC conversation as per request from x1sc0:

steve: do you happen to know if there are any plans to address the missing quicklook feature on macOS? #35361. it’s one of the more popular requests for macOS and a very basic functionality. it’s well documented and almost all apps that handle files do support it, so LO sticks out in a bad way in that regard
x1sc0: no idea, maybe tor is up for it
steve: sorry for being annoying about quicklook, but is that something to be brought up in ESC call? or is there any way to bring this feature request to devs attention?
x1sc0: well, it could be brought, but being honest, it’s a request from 2011-03-16, it seems more like a pet bug. any specific reason why I should bring it now, after all these years ?
steve: o specific reason to bring it up now. but doesn’t change that I feel it should have been fixed 2010 actually or whenever quicklook was first introduced. it’s just very inconvenient and uncommon to not see a files content when browsing files in finder (macOS file browser). so LibreOffice sticks out like a bad fish because I have to think really hard to think of another app not supporting quicklook. no specific argument to bring it up now, but still strong feeling it should be addressed and the fact that it has not been addressed for 7 years makes me worried.
x1sc0: what about sending a nice email to the board or the dev list explaining why it should be implemented and suggesting it as tender ?
steve: x1sc0 I can do that maybe around the holiday season when I have more time. I will ping regarding who to address then.
x1sc0: mmeeks, do you think my suggestion to steve-_- makes sense ?
mmeeks: x1sc0, steve-_- so - yes, please do assign that to Tor - we have some budget to look into OSX features in the new year - and (I think) this was one that is on our radar.

Dear Tor Lillqvist,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.

Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20

I'm supporting this request. Quicklook support is actually a basic requirement on macOS for at least 8 years now. Please try to find a way to implement it. Thanks!

*** Bug 164150 has been marked as a duplicate of this bug. ***

macOS is able to show preview of file in the Finder.
This works well for
Microsoft Office Word, Excel and PowerPoint files (docx, xlsx, pptx),
even when the docx-file is created with LibreOffice, NeoOffice, SoftMaker Office,
even when the xlsx-file is created with LibreOffice, NeoOffice, SoftMaker Office,
even when the pptx-file is created with LibreOffice, NeoOffice, SoftMaker Office.
LibreOffice
Text odt: yes
Tabelle/Spreadsheet ods: macOS 11.7 Big Sur yes, macOS 14.7 Sonoma no
Präsentation/Presentation odp: macOS 11.7 Big Sur yes, 14.7 blurred (pixels to guess from)
NeoOffice 
Text/Writer odt yes
Tabelle/Calc ods: macOS 11.7 Big Sur yes, macOS 14.7 Sonoma no
Präsentation/Presentation odp: macOS 11.7 Big Sur yes, 14.7 blurred (pixels to guess from)
SoftMaker Office
TextMaker tmdx: no (icon only)
PlanMaker pmdx: no (icon only)
Presentations

Quick Look for odt-files made by LibreOffice Text, Microsoft Word, NeoOffice Writer;
No Quick Look for ods-files made by LibreOffice (for 14.7), Excel, NeoOffice;
Blurred Quick Look for opd-files made by LibreOffice (for 14.7), PowerPoint, NeoOffice.

Obviously there is some code that allows Microsoft Office documents formats 
and odt-files made from all office suites to show a preview (thumbnail image) in the finder.
Please put this code also into LibreOffice spreadsheet and presentation editors so that also ods- and odp-files will have their preview in the sidecolumn!

*** Bug 164150 has been marked as a duplicate of this bug. ***
So my feature request of Dec4 2024 is a duplicate of a feature request from 2011-03-16 – I'd be happy if someone took care of this!

So this bug popped up in one of my routine macOS bug searches. I admit that I didn't read more than a few recent comments as I it has been years since I last looked at NeoOffice's Quick Look code but I still remember roughly how that code works.

IIRC, it only worked for .od* documents and did not work with any Microsoft Office file formats. Also, it had one other restriction: it only worked if the .od* file was saved by NeoOffice.

On my macOS Sequoia laptop I have the free Microsoft Office from the Mac App Store and saving a .xlsx and .pptx in LibreOffice shows a detailed thumbnail in the Finder. .odt and .docx both show a detailed thumbnail in Finder but, IIRC, they are handled by Apple's built-in Quick Loop plugin.

So I guess my question is: what is missing at this point in time? It appears that the only formats that are missing Quick Loop support are the following LibreOffice file formats:

.ods
.odp
.odg
.odb
.odf
.odm

If we are only missing Quick Look support for LibreOffice file formats, then the NeoOffice approach might work. I did a quick test of the above LibreOffice file formats and all except .odb embed a .png thumbnail of the first page of the document in the .od* file when saving.

Created attachment 197967 [details]
Thumbnail saved in .odt file

This attachment is a sample of the .png file that LibreOffice embeds in an .odt file. Seems large enough to be used for Quick Look to me but who knows.

Patrick, thanks for taking a look at this. odt files indeed show a quicklook preview and as you correctly stated the other file formats do not.

If you find a way to add support for the other formats that would be a huge step for LO on macOS. This is one of the most common feature requests for LO on macOS and macOS users have come to expect quicklook support from applications that handle files.

There is room for improvements as to what is shown in the odt quicklook preview, as various elements do not show. But priority wise support for the remaining types would be much more important than fine tuning quicklook for the one supported format imo.

(In reply to steve from comment #81)
> If you find a way to add support for the other formats that would be a huge
> step for LO on macOS. This is one of the most common feature requests for LO
> on macOS and macOS users have come to expect quicklook support from
> applications that handle files.

Let me set expections: I am not going to "figure out" support for other formats. What I am proposing is to investigate if NeoOffice's Quick Look plugin will work with the .png thumbnail that LibreOffice inserts into most .od* files when saving.

Assuming the NeoOffice Quick Look plugin can be made to work in LibreOffice, you will only see a Quick Look image if your .od* has an embedded .png thumbnail. No thumbnail (e.g. if an .od* file was saved in another app like TextEdit or Microsoft Office that does not embed thumbnails), no Quick Look preview.

TDF does not fund any dedicated macOS developers. All macOS bug fixes and features are handled (or not) by a very small number of volunteers donating their time like me. That is the most likely the reason why this bug has been open since 2011: it looks like a massive project to implement a Quick Look plugin that read and render your document without launching LibreOffice.

I am a volunteer who fixes LibreOffice bugs as a hobby in my spare. I don't have the time (or money to fund other developers) to implement what you want so there is no "second phase" in my plans. I can spare a little time to try to copy the NeoOffice code over to LibreOffice.

It's a hacky solution and maybe not what anybody wants, but it is probably the most I can do in my spare time. If that isn't good enough, then I recommend that macOS users and/or organizations pool their funds and approach a LibreOffice ecosystem partner like Collabora, Allotropia, etc. AFAICT most new features in LibreOffice are funded by users and/or organizations paying an ecosystem partner to implement their desired features. Note: I am not an ecosystem partner, I only volunteer because I use LibreOffice to maintain all of spreadsheets for my non-LibreOffice work.

> There is room for improvements as to what is shown in the odt quicklook
> preview, as various elements do not show. But priority wise support for the
> remaining types would be much more important than fine tuning quicklook for
> the one supported format imo.

I highly doubt that I will be able to override Apple's built-in .odt plugin. In my experience, macOS uses an undocumented algorithm for which Quick Look plugins handle which file formats. Once macOS chooses a plugin, that plugin appears to be called for all files of a particular format. You can force your once plugin to be used when testing using the "qlmanage" command, but macOS chooses which plugin for the Finder.

So, even if we could force macOS to use the NeoOffice plugin, macOS would call our plugin for all .odt files (even if created by TextEdit or Microsoft Office) on your machine. IIRC, the NeoOffice plugin tries to call Apple's built-in .odt plugin if an .odt file doesn't have an embedded thumbnail, but I vaguely remember that that macOS stopped calling the NeoOffice plugin for .odt files several versions of macOS ago and macOS would always use Apple's built-in .odt plugin.

Realistically, I think we all need to keep our expectations low. Right now, the NeoOffice Quick Look plugin bundled with my NeoOffice installation does not even load on macOS Sequoia so this idea may end up being a dead-end. So it looks like the first step needed is to compile and debug the NeoOffice Quick Look plugin on macOS Sequoia.

Forgot I added the link to the NeoOffice Quick Look plugin (aka NeoPeek) source code:

https://github.com/neooffice/NeoPeek

Overall, the code logic is pretty simple:
1. macOS calls the plugin and passes an .od* file path and a drawing surface
2. The plugin opens the .od* file, unzips the file, and looks for an embedded thumbnail file
3. If an embedded thumbnail file is found, the plugin copies the image bits and draws the image to the drawing surface passed in by macOS
4. macOS then handles displaying the drawn copy of the thumbnail

Created attachment 198011 [details]
Xcode project with prototype Quick Look plugin

I was able to compile the NeoOffice Quick Look plugin (aka NeoPeek) on my macOS Sequoia machine but it still would not load. After some web searches, I found that Apple has a new API for Quick Look plugins and the old API, which NeoPeek uses, was apparently not included in macOS Sequoia.

So created a prototype Quick Look plugin project in Xcode using the new API. My Xcode project doesn't do much, but I am able to get the Quick Look plugin to load.

Right now, my Xcode project only displays the intro.png bundled in a local LibreOffice installation as I just wanted to figure out how to get an image that autoresizes to display in the Finder and Finder's Quick Look window.

Next step is to try to implement display of the embedded thumbnail in the selected .od* file if one exists. My plan is to modify LibreOffice's Spotlight code to find any thumbnails in a .od* file's zip entries, then unzip the thumbnail entry, and create an NSImage from the thumbnail bytes.

Created attachment 198012 [details]
Snapshot of Finder displaying image from prototype Quick Look plugin

This is a snapshot of what my Xcode project in attachment #198011 [details] does. Nothing particularly impressive, but it confirms that we can reimplement the NeoPeek approach using Apple's new API to load and autoresize .png thumbnail images.

Great news to see that someone is working on the preview again! :-)
Thanks for your work!

Did you put your prototype on github?


Again: thank you very much for your work!!

(In reply to Oliver from comment #86)
> Did you put your prototype on github?

No. Right now it is in the zip file in attachment #198011 [details]. The prototype is really just a "quick and dirty" experiment to see how Apple builds and packages an "app extension".

AFAICT, the LibreOffice build doesn't build Xcode projects so once I have a working demo that can extract embedded thumbnails from an .od* file in Xcode (I'll attach another Xcode project zip file hopefully later this week), then the last (and probably most tedious) step will be for me to copy the minimum subset of Xcode files into the LibreOffice build and add makefile changes to package and bundle the Quick Look application extension into LibreOffice.

LibreOffice currently builds its Spotlight plugin without Xcode using makefiles so my plan is to copy build and packaging commands for that and modify the commands as necessary to replicate what Xcode builds.

In theory, I should only need to merge the following files in the zip in attachment #198011 [details]:

MyQuickLookPreviewExtension/PreviewViewController.h
MyQuickLookPreviewExtension/MyQuickLookPreviewExtension.entitlements
MyQuickLookPreviewExtension/PreviewViewController.m
MyQuickLookPreviewExtension/Info.plist

In MyQuickLookPreviewExtension/PreviewViewController.m there really isn't much code at all needed to display a hardcoded image. The only thing I need to do before integrating my Xcode project into the LibreOffice build is to replace displaying a hardcoded image with displaying the thumbnail (if it exists) from an .od* file.

I am confident that with some minor modifications to LibreOffice's Spotlight plugin files (i.e. the extensions/source/macosx/spotlight/OOo* files in the LibreOffice sources), I can extract a thumbnail from an .od* file.

I'll post another update later this week.

Created attachment 198085 [details]
Xcode project that implements Quick Look for all .od* files that have an embedded thumbnail

Created attachment 198086 [details]
Snapshot of Quick Look preview window and Finder

The snapshot was taken in the Finder and its Quick View window using the Xcode project in attachment #198085 [details].

It works with all .od* files that have an embedded thumbnail image so it will also work with .od* files saved in OpenOffice, NeoOffice, and LibreOffice.

Note: macOS appears to use their own Quick Look plugin for .odt files even though I have included .odt support in my plugin.

So the next step is to add the files in attachment #198085 [details] to the source code in LibreOffice extensions/source/macosx.

Created attachment 198105 [details]
Xcode project that adds a second app extension for creating icons in the Finder

Created attachment 198106 [details]
Snapshot of icons for .odp files in the Finder

This snapshot shows another piece of Quick Look functionality that I have prototyped.

After doing more experimenting with my last Xcode project in attachment #198085 [details], I noticed that the Finder was still showing the generic icons for .od* files and only that Xcode project only worked in the "preview panel" when you selected a file in the Finder or displayed the file using the Finder's File > Quick Look menu item.

Apparently, Apple has a different API for displaying custom file icons:

https://developer.apple.com/documentation/quicklookthumbnailing/providing-thumbnails-of-your-custom-file-types

So I uploaded a new Xcode project in attachment #198105 [details] that includes a second app extension that implements the above API.

Note for future testing: forcing the Finder to regenerate a file icon is not obvious. I found the following article that appears to work (at least when Xcode isn't running):

https://www.macrumors.com/how-to/fix-macos-file-icon-previews-not-showing/

Created attachment 198391 [details]
Snapshot of Quick Look settings on macOS Sequoia after installing LibreOffice local build with new plugins

I have finally finishes copy the Quick Look code in attachment #198105 [details] into the LibreOffice build in the following patch:

https://gerrit.libreoffice.org/c/core/+/178393

The patch still needs to be reviewed, but the above snapshot shows how the new extensions are enabled or disabled.

*** Bug 103177 has been marked as a duplicate of this bug. ***

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3eb7cdd6eca9ee557282e9f11f27958fed395617

tdf#35361 Add a Quick Look plugins for .od* files on macOS

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

My Quick Look code has been committed and Quick Look support should be in tomorrow's (11 January 2025) nightly master builds: 

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Once you install a nightly master build that has my Quick Look code (download and installation steps are in comment #95), launching the nightly master build form the Finder (its installed in /Applications/LibreOfficeDev.app) should register the plugins bundled with the download.

Once you have launched LibreOfficeDev.app, launch the System Preferences application, navigate to the Login Items & Extensions panel, and in the Extensions section, click on the icon next to the Quick Look entry to see a list of installed extensions.

If macOS has successfully found and loaded the plugins, there should be the following two extensions. Enable both if either is disabled:

- LibreOffice Quick Look Preview
- LibreOffice Quick Look Thumbnail
 
Then, force the Finder to regenerate its previews and thumbnails by relaunching the Finder. To relaunch the Finder, press Command-Option-Escape, select the Finder in the dialog that appears, and press the Relaunch button.

Important note: it appears that Apple's bundled .odt plugin will always be used for .odt files. Our plugins support .odt, but macOS will ignore plugins and use its own bundled plugins. Unfortunately, I have found no way to disable Apple's bundled plugins.

Thanks for your work, Patrick!

Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: c9ae567c791bcffdc3fff9e3fb11b46275a13d2b
CPU threads: 12; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

Two items appear in System Settings > General > Login Items & Extensions > Quick Look, which are both disabled. Enabled both manually and relaunched finder.

The file icons were regenerated and include a preview, also pressing spacebar shows Quick Look previews for Calc files, which was not possible before.

Wondering about the small area used for the calc preview and how that is generated for the png file used by LibreOffice. Do you think it's worth filing an enhancement to take content into consideration for calc when generating the preview png?

Impress files also work fine. This is a huge improvement.

For writer it seems odd, as LibreOffice does not create a preview png using images used in the header but just generates a quick look preview with the text lacking the header image / text area entirely and other UI elements which are not text. This is surprising as Impress Quick Look preview shows images fine. Another enhancement request worth filing?

(In reply to steve from comment #97)
> For writer it seems odd, as LibreOffice does not create a preview png using
> images used in the header but just generates a quick look preview with the
> text lacking the header image / text area entirely and other UI elements
> which are not text. This is surprising as Impress Quick Look preview shows
> images fine. Another enhancement request worth filing?

I believe I covered this at the very end of comment #96: Apple has its own plugins for .odt files that overrides our plugins and there is no way that I can see for users to disable the Quick Look plugins that Apple has bundled with macOS.

Nevertheless, I have included .odt support in our plugins in case Apple allows disabling their bundled macOS plugins in the future.

Created attachment 198498 [details]
Test document for determining if the Finder is using ours or Apple's .odt plugins

Some troubleshooting info: I use this attachment to quickly test if Apple's or our Quick Look plugins are being used by the Finder.

It has emojis and Japanese characters. If the Finder is using our plugin, you will see a white background (even in dark mode) and there will be several vertical lines in the top right corner.

However, if the Finder is using Apple's plugin, the background will be black when in dark mode and there will not be any vertical lines.

Read that part. Hmm, do you consider the behavior from macOS misbehavior from Apple's side? I find it odd, they just overrule LibreOffice's implementation.

Was wondering if this was related to having Pages app installed from Apple, so uninstall all Apple Office apps, but that did not change anything in regards to the odt preview coming from macOS.

Would you consider the macOS behavior a bug? Should this be reported to Apple (not that there's much hope they would care and will address anything)?

(In reply to steve from comment #100)
> Was wondering if this was related to having Pages app installed from Apple,
> so uninstall all Apple Office apps, but that did not change anything in
> regards to the odt preview coming from macOS.

It's a system plugin in /System/Library/QuickLook/Text.qlgenerator. Good luck deleting it as it is protected by "macOS rootless" security. Seems Apple really wants it there but feel free to file a bug or enhancement request with Apple.

I do apologize if I'm talking gibberish here. It's been decades since I last did any serious work of this kind, but - this is just an idea - is it maybe possible that terminal utility qlmanage with -g switch ("force the generator to use") might override the the default qlgenerator for ODT?

A dirty hack would be to directly edit this file

/System/Library/QuickLook/Text.qlgenerator/Contents/Info.plist 

and remove this line

<string>org.oasis-open.opendocument.text</string>

Of course, this involves low level single user access or disabling SIP, or both... :-) but it is in any case less invasive then actually deleting the system stock QL generator that is used for a number of other filetypes.

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

https://git.libreoffice.org/core/commit/cd22b2041af70c290a1e5cac71cdbefec56b99cc

tdf#35361 Add a Quick Look plugins for .od* files on macOS

It will be available in 25.2.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Note: I have created the following Wiki page. Feel free to add or edit anything:

https://wiki.documentfoundation.org/MacOS/Quick_Look

I expect that more troubleshooting tips will be added over time.

For the .odt issue where user needs to change their system setup or Apple needs to update their quickview implementation to render thumbnails correctly, here is a work around to consider is to:

1) Allow the user to save files to another extension such as .odx
2) Allow the new quicklook functionality to work with .odt and the alt .odx

The alt extension could be configured as the default by the user or set as the default going forward.

This removes the dependency from Apple and provides a simpler solution for end users.

(In reply to Patrick (volunteer) from comment #92)
> Created attachment 198391 [details]
> Snapshot of Quick Look settings on macOS Sequoia after installing
> LibreOffice local build with new plugins

Thanks for this great addition, Patrick.
Can we use your screenshot for the Release Notes?

(In reply to Stéphane Guillou (stragu) from comment #107)
> Thanks for this great addition, Patrick.
> Can we use your screenshot for the Release Notes?

I would request that you use the screenshots in the following LibreOffice Wiki article as they don't have any personal data or any background clutter:

https://wiki.documentfoundation.org/MacOS/Quick_Look

Thanks Patrick. Added here, please feel free to change it:

https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F25.2&type=revision&diff=785642&oldid=785433