Created attachment 102293 [details] Mac OS X: LO 4.3 Rendering In 4.3, LO rendering is suboptimal. Does not affect text rendering only (which has been an issue in Mac OS for some time) but the whole UI, including window system buttons. See attached scereenshot with a document from 4.3 (the blur is not a result of because of image compression).
Created attachment 102294 [details] Mac OS X: LO 4.2 Rendering (for comparison)
Confirmed, also still present on the latest stable.
It looks like the LibreOffice.app/Contents/Info.plist shows a "false" value for NSHighResolutionCapable causing it to not use retina text rendering. You need to change this: <key>NSHighResolutionCapable</key> <false/> To this: <key>NSHighResolutionCapable</key> <true/> Note: if you want to fix an existing copy of LibreOffice, you need to update the Info.plist, then rename LibreOffice.app to something else like LibreOffice2.app, open the application and see that retina works, then close and rename it back to LibreOffice.app. I'm not sure how else to clear the cached value but that works. Also, kinda sucks that this wasn't fixed before 4.3 was released today.
Relevant: http://opengrok.libreoffice.org/xref/core/configure.ac#3089 @Norbert: any idea on why the Info.plist file doesn’t contain the correct value?
Changing the info.plist as suggested in Comment #3 works. However, it also triggers Gatekeeper and either an exception has to be manually added or Gatekeeper protection turned off. As this bug seems to be extremely easy to fix and is extremely annoying for retina users, can this be addressed via a hotfix?
*** Bug 81915 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > As this bug seems to be extremely easy to fix and is extremely annoying for > retina users, can this be addressed via a hotfix? Sure, should a patch be done in time--look for it in 4.3.1 first incremental release https://wiki.documentfoundation.org/ReleasePlan/4.3#4.3.1_release
the release build was not build with --enable-macosx-retina I will add that to the next release build. (but only for the SDK 10.8 / 64bits build)
Looks like this is now also fixed (retina-enabled) by default for current master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=5fcd0d9c1e27878e1d31891eee669fe5ae55a8e6 thanks to Norbert. @Norbert: I guess we can close this bug now :)?
Just downloaded the 4.3.1.2 update and the plist is still using a FALSE value, when is sthis supposed to hit a public release? Also manually changing the plist is now causing a corruption error when trying to load the app bundle (Yosemite public beta 3).
(In reply to comment #8) > the release build was not build with --enable-macosx-retina > > I will add that to the next release build. (but only for the SDK 10.8 / > 64bits build) Norbert - Did this make it into 4.3.2? (If not, should it be in 4.3.3?) Status -> NEW
NEEDINFO as of Comment 11. Could someone with a retina mac please test 4.3.3.1: https://www.libreoffice.org/download/pre-releases/ If this persists, please back to NEW. Otherwise FIXED. No retina here, so can't test.
Tested, issue still persists in 4.3.3.1. Status changed back to NEW.
UPDATE: Re-tested again with the 64bit build (after I noticed in the discussion that the fix was applied to the 64bit version only). Issue FIXED there. Changing status to NEEDINFO again, as I am not sure whether there should be a deliberate inconsistency between the 64bit and 32bit builds – in particular considering that the 32bit version is downloaded by default unless you specifically switch to the 64bit version on the download page meaning that most retina users will suffer from this bug. Sorry for 2 posts and 2 status changes.
(In reply to Dan from comment #14) > Re-tested again with the 64bit build (after I noticed in the discussion that > the fix was applied to the 64bit version only). Issue FIXED there. Good. > Changing status to NEEDINFO again, as I am not sure whether there should be > a deliberate inconsistency between the 64bit and 32bit builds Note Norbert's comment above: "[I'll enable retina support] but only for the SDK 10.8 / 64bits build" > ...considering that the 32bit version is downloaded by default > unless you specifically switch to the 64bit version on the download page > meaning that most retina users will suffer from this bug. All of the OS X builds will require 10.8+ and be 64bit-only as of the next Release Branch (4.4.x), so it might be best for all retina users to upgrade their OS now. Do we not detect 64bit OS X on the download page? Fixing that could be a good stopgap until 4.4.0 comes out at the end of January.
This bug is still present in 4.3.3 that was released recently.
I apologize for the second comment, but wanted to elaborate -- the 32-bit build is still broken with respect to retina (and was the default download). There is no technical reason I know that would prevent 32-bit builds from having retina graphics. In fact, manually changing the Info.plist on the 32-bit build fixes the retina rendering as far as I can tell. It would be nice if we could have it fixed for both builds or document the reason why it should be disabled.
the reason I did not change the 32 bits version is that if you have a retina capable mac, you should really be using the 64 bits version.
note: one could not have bought a retina mac with OSX < 10.8 one could not have bought a retina mac with a 32 bits processor so any mac out there that could benefit from the retina support is 64 bit and >= 10.8 and hence should be using the 64bits build
btw: "in particular considering that the 32bit version is downloaded by default unless you specifically switch to the 64bit version on the download page" is not correct. the download page does point you to the 64 bits version if mac osx 10.8+ is detected
(In reply to Norbert Thiebaud from comment #19) > note: one could not have bought a retina mac with OSX < 10.8 > one could not have bought a retina mac with a 32 bits processor > so any mac out there that could benefit from the retina support > is 64 bit and >= 10.8 and hence should be using the 64bits build Of course there will be corner cases of OS X <=10.6 being run 32-bit on a VM (Fusion or Parallels) hosted on a >=10.8 system and having use of Retina display hardware. So just maybe... Guess folks are not aware that at some point we really just have to cut the 32-bit development off because of obsolete compiler support. And currently no TB is building a 32-bit of Master for OS X <=10.6 I believe the correct statement is that 32-bit OS X support ends with the 4.3 branch final EOL next May--folks should be transitioning hardware and OS.
"And currently no TB is building a 32-bit of Master for OS X <=10.6" well nitpick but no tb could be building Master for OSX < 10.8 master required SDK 10.8+ and the toolchain that comes with it. 4.3 and 4.2 are not buildable with anything < 10.6 Also I have only one box left with 10.6.. that is the box I use to build release build for 4.2 and 4.3... looking forward to next May indeed. oh, and one last thing: the binaries for all libreoffice version are still available. people with a 10.4 PPC mac can still find a binary.. just not the most advanced version of libreoffice.. but a version that is as advance, and more, as their OS version is.
@Norbert--sorry, no intention of nit-picking. We just need folks to be realistic about what is and is not possible, and move on. To support the VM usage corner case, can the 32-bit builds be compiled with --enable-macosx-retina flag? Will it build, will it be stable for use. If not, there you go... And for anyone interested the archive is here: http://downloadarchive.documentfoundation.org/libreoffice/old/
I selected the default download which is named: LibreOffice_4.3.3_MacOS_x86-64.dmg Thus I assume it is the 64bit build, and yet retina display is still broken by default, I read this should be fixed for 64bit builds by now?
I can confirm that it is still broken in the current LibreOffice_4.3.3_MacOS_x86-64 download, on OS X 10.10. Per comment 3, in LibreOffice.app/Contents/Info.plist, <key>NSHighResolutionCapable</key> was <false/>. Oddly, changing this to <true/> (and restarting the application) did not fix the issue, whereas it had done previously when I tried it with 4.3.2.
Could you please check, if this persists with the latest nightly as well? Download and install the latest dev build from: http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/ No retiana here, sorry - so can't test myself.
master~2014-10-31_03.27.20_LibreOfficeDev_4.4.0.0.alpha1_MacOS_x86-64.dmg looks fine here.
*** Bug 85826 has been marked as a duplicate of this bug. ***
(In reply to PT from comment #25) > I can confirm that it is still broken in the current > LibreOffice_4.3.3_MacOS_x86-64 download, on OS X 10.10. > > Per comment 3, in LibreOffice.app/Contents/Info.plist, > <key>NSHighResolutionCapable</key> was <false/>. Oddly, changing this to > <true/> (and restarting the application) did not fix the issue, whereas it > had done previously when I tried it with 4.3.2. To fix the issue, restart in not enough. Follow the steps I described in https://bugs.freedesktop.org/show_bug.cgi?id=85826 Yannick
This bug has been fixed in LibreOffice 4.3.4.1 version (released Nov 14, 2014). The Info.plist file is now correct and rendering is as expected on my end of 2013 retina MacBook Pro (id model 11,3 - 2.3 GHz Intel Core i7 - 16 GB RAM) running Mac OS X 10.9.5. I think we can close this bug as fixed, but since I didn't open it, I prefer let somebody else do it. Regards, Yannick Chiron
I'm having the same problem, although I downloaded today's (Nov 16) developer version and its fixed in that. But the download from the website, which I see is still dates Nov 11, has the problem. Am I right to assume that that one will be updated in the next few days? Many thanks, Tom
Please stop reopening this bug - it is fixed. If you just have a question - leave a comment and hopefully someone will respond. Again - this bug is FIXED so reopening it just is a waste of everyone's time. Thanks
Apologies, I wasn't sure where to ask the question but realise this was not the right place. Regards, Tom
(In reply to Robinson Tryon (qubit) from comment #15) > All of the OS X builds will require 10.8+ and be 64bit-only as of the next > Release Branch (4.4.x), so it might be best for all retina users to upgrade > their OS now. > > Do we not detect 64bit OS X on the download page? Fixing that could be a > good stopgap until 4.4.0 comes out at the end of January. OS X has been 64 bit for a long time (since 10.6). All Mac with retina display run 64 bit version of OS X. The problem is providing a 32 bit when a 64 bit should be provided by default. 4.3.4 downloaded today still has the bug. And obviously 64 bit detection on your website, if it exists, does not work.
(In reply to plessard from comment #35) > (In reply to Robinson Tryon (qubit) from comment #15) > > All of the OS X builds will require 10.8+ and be 64bit-only as of the next > > Release Branch (4.4.x), so it might be best for all retina users to upgrade > > their OS now. > > > > Do we not detect 64bit OS X on the download page? Fixing that could be a > > good stopgap until 4.4.0 comes out at the end of January. > > OS X has been 64 bit for a long time (since 10.6). All Mac with retina > display run 64 bit version of OS X. The problem is providing a 32 bit when a > 64 bit should be provided by default. 4.3.4 downloaded today still has the > bug. And obviously 64 bit detection on your website, if it exists, does not > work. Well I don't know why but the server gave me a non 64 bit version the first time. The second time I got the 64 bit version and everything is correct.
That's what I was pointing out earlier. The 64-bit detection on the website does *NOT* work properly for the OS X platform and the 32-bit version is selected by default. That is why I tried to persuade the devs to: (a) fix the 32-bit version as well (as the fix seems to be VERY quick and easy); and/or (b) fix the website to default to the 64-bit version (may even be HARDCODED if the detection system does not work). I will not reopen the bug, but it should be looked into further; in fact, a new ticket should be opened for the website 32/64-bit detection logic, which is plainly flawed and makes this bug reappear time and again. In the current situation, the OS X public has to face an unnecessarily bad experience when trying to switch over to LO and it can dissuade potential new users. With the amount of OS X devices growing steadily, this market niche deserves the attention. There are many other OS X related bugs, but this one is entirely unnecessary, especially since it is a showstopper for most new users. [Hope I do not sound like a blinded Apple fanboy, these are just plain facts.] (In reply to plessard from comment #36) > (In reply to plessard from comment #35) > > (In reply to Robinson Tryon (qubit) from comment #15) > > > All of the OS X builds will require 10.8+ and be 64bit-only as of the next > > > Release Branch (4.4.x), so it might be best for all retina users to upgrade > > > their OS now. > > > > > > Do we not detect 64bit OS X on the download page? Fixing that could be a > > > good stopgap until 4.4.0 comes out at the end of January. > > > > OS X has been 64 bit for a long time (since 10.6). All Mac with retina > > display run 64 bit version of OS X. The problem is providing a 32 bit when a > > 64 bit should be provided by default. 4.3.4 downloaded today still has the > > bug. And obviously 64 bit detection on your website, if it exists, does not > > work. > > Well I don't know why but the server gave me a non 64 bit version the first > time. The second time I got the 64 bit version and everything is correct.
(In reply to Dan from comment #37) > The 64-bit detection on the website > does *NOT* work properly for the OS X platform and the 32-bit version is > selected by default. > ... > I will not reopen the bug, but it should be looked into further; in fact, a > new ticket should be opened for the website 32/64-bit detection logic, which > is plainly flawed and makes this bug reappear time and again. +1 Opening a new bug specifically for the OS/architecture-detection code on the website sounds like the best plan. Please leave a comment linking to that bug report to make it easy for people to follow the progression. Thanks!
*** Bug 88516 has been marked as a duplicate of this bug. ***