https://bugs.documentfoundation.org/show_bug.cgi?id=35361
--- Comment #82 from Patrick (volunteer) <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
