I just noticed that the quicklook thumbnails and preview of LO 3.3.1
docs does not work in snow leopard (you get app icon instead of view of
doc.) Am not really sure whether this is consistent with OOo behavior,
but thumbnails do work for MSO files so is this related to the lack of a
plugin, misconfiguration or other issue? I did find this
Would somebody using OSX have a look? Thanks!
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.
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).
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.
This OSX 10.6.6 system had LO 3.3 installed after OOo had been installed and is currently running:
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)
> 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-126.96.36.199
> 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....
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 - 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:
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
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.
(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.
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 ;-)
I can't upload neopeek.qlgenerator because it is an app bundle, and freedesktop refuses to take it. The bundle contains :
I can try and post the binary (assuming freedesktop lets me), but its probably not much good to you without the rest.
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 :
In the OOo code, the quicklookplugin01 CWS is/was supposed to be integrated into OOo version 3.4.
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
Have you found an actual build of the file that is targeted for OOo3.4?
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...
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.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
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?
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
This is bullshit!
The bug still remains in the current version and we have been at pains to document it and provide detail of how to ddress it, and after all that someone just posts, "sorry, we can't be bothered?" Give me a break.....
"Version" is most old version where bug is reproducible. Not current version.
Changing to 3.3.1 back
Try reading the damned documentation!
"Version: The "Version" field is usually used for versions of a product which have been released, and is set to indicate which versions of a Component have the particular problem the bug report is about."
If you want people to use this tool in some specific fashion, update the context help or bugger off.
This bug has been clearly documented for some time, and more dev time has been spent trying to fiddle the listing than would have been necessary to resolve it.
PLEASE LEAVE IT AT THE OLDEST REPRODUCABLE VERSION - Thanks
Seeing you boasting here:
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:
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.
Sorry for the inconvenience.
I have returned this bug to the status Florian placed it in (https://bugs.freedesktop.org/show_bug.cgi?id=35361#c34)
Have a nice day. You will not be hearing from me again
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 188.8.131.52) 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.
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.
Recap of progress on this bug (i.e. a failure of functionality.)
* Opened and documented 2 years ago. Questions posted, answers to which could possibly resolve issue
* Redocumented a year ago because report reclassified as NEEDINFO because of administrative confusion
* Reclassified as an "enhancement" two years after initially reported and documented. A summary seems to be inconsistent with the reported data and there is still no evidence that anyone has looked at the underlying issue or suggestions.
Seems that this means that the new LO term for broken is unenhanced and the likelihood of getting this functionality back continues to diminish ;-)
(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.
*** Bug 59553 has been marked as a duplicate of this bug. ***
*** Bug 36431 has been marked as a duplicate of this bug. ***
Although I do not like the tone of the thread in the last few messages, I agree that this would be a very nice feature to have (with or without installing LibreOffice).
*** Bug 81589 has been marked as a duplicate of this bug. ***
REOPENED is not the correct status - setting to NEW.
The status is now listed as "new" "low", lol.....
Adding self to CC if not already on
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 184.108.40.206 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.