Bug 80939 - Mac OS X: LibreOffice windows are pixelated on Retina displays
Summary: Mac OS X: LibreOffice windows are pixelated on Retina displays
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.3.0.2 rc
Hardware: Other Mac OS X (All)
: highest major
Assignee: Not Assigned
URL:
Whiteboard: target:4.4.0
Keywords:
: 81915 85826 88516 (view as bug list)
Depends on:
Blocks: MacOS-Wishlist mab4.3
  Show dependency treegraph
 
Reported: 2014-07-05 09:08 UTC by Dan
Modified: 2015-01-17 14:10 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Mac OS X: LO 4.3 Rendering (192.47 KB, image/png)
2014-07-05 09:08 UTC, Dan
Details
Mac OS X: LO 4.2 Rendering (for comparison) (235.63 KB, image/png)
2014-07-05 09:09 UTC, Dan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan 2014-07-05 09:08:43 UTC
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).
Comment 1 Dan 2014-07-05 09:09:50 UTC
Created attachment 102294 [details]
Mac OS X: LO 4.2 Rendering (for comparison)
Comment 2 Maarten Brouwers 2014-07-30 11:05:18 UTC
Confirmed, also still present on the latest stable.
Comment 3 mrjbq7 2014-07-30 14:52:04 UTC
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.
Comment 4 Adolfo Jayme 2014-07-30 18:39:45 UTC
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?
Comment 5 Dan 2014-07-30 21:24:29 UTC
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?
Comment 6 Adolfo Jayme 2014-07-31 02:26:42 UTC
*** Bug 81915 has been marked as a duplicate of this bug. ***
Comment 7 V Stuart Foote 2014-08-02 16:13:01 UTC
(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
Comment 8 Norbert Thiebaud 2014-08-04 21:50:29 UTC
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)
Comment 9 Jorendc 2014-09-13 19:23:43 UTC
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 :)?
Comment 10 Iandol 2014-09-17 04:26:55 UTC
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).
Comment 11 Robinson Tryon (qubit) 2014-09-26 01:56:22 UTC
(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
Comment 12 retired 2014-10-20 09:21:58 UTC
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.
Comment 13 Dan 2014-10-20 09:54:32 UTC
Tested, issue still persists in 4.3.3.1.

Status changed back to NEW.
Comment 14 Dan 2014-10-20 10:04:10 UTC
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.
Comment 15 Robinson Tryon (qubit) 2014-10-20 10:25:51 UTC
(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.
Comment 16 mrjbq7 2014-10-30 16:48:50 UTC
This bug is still present in 4.3.3 that was released recently.
Comment 17 mrjbq7 2014-10-30 17:02:32 UTC
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.
Comment 18 Norbert Thiebaud 2014-10-30 18:24:10 UTC
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.
Comment 19 Norbert Thiebaud 2014-10-30 18:26:47 UTC
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
Comment 20 Norbert Thiebaud 2014-10-30 19:15:34 UTC
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
Comment 21 V Stuart Foote 2014-10-30 20:17:14 UTC
(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.
Comment 22 Norbert Thiebaud 2014-10-30 20:24:56 UTC
"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.
Comment 23 V Stuart Foote 2014-10-30 20:56:13 UTC
@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/
Comment 24 Iandol 2014-10-31 08:44:34 UTC
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?
Comment 25 PT 2014-10-31 08:55:22 UTC
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.
Comment 26 retired 2014-10-31 12:49:55 UTC
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.
Comment 27 PT 2014-10-31 13:05:16 UTC
master~2014-10-31_03.27.20_LibreOfficeDev_4.4.0.0.alpha1_MacOS_x86-64.dmg looks fine here.
Comment 28 Adolfo Jayme 2014-11-04 04:35:31 UTC
*** Bug 85826 has been marked as a duplicate of this bug. ***
Comment 29 Yannick Chiron 2014-11-06 09:23:51 UTC
(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
Comment 30 Yannick Chiron 2014-11-14 13:50:51 UTC
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
Comment 31 Adolfo Jayme 2014-11-14 14:23:31 UTC
*** Bug 85826 has been marked as a duplicate of this bug. ***
Comment 32 tomneumark 2014-11-16 21:52:01 UTC
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
Comment 33 Joel Madero 2014-11-16 23:07:32 UTC
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
Comment 34 tomneumark 2014-11-17 07:36:15 UTC
Apologies, I wasn't sure where to ask the question but realise this was not the right place.

Regards, Tom
Comment 35 plessard 2014-12-02 03:59:34 UTC
(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.
Comment 36 plessard 2014-12-02 04:08:34 UTC
(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.
Comment 37 Dan 2014-12-02 06:23:51 UTC
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.
Comment 38 Robinson Tryon (qubit) 2014-12-02 12:15:05 UTC
(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!
Comment 39 Adolfo Jayme 2015-01-17 14:10:11 UTC
*** Bug 88516 has been marked as a duplicate of this bug. ***