Download it now!
Bug 138122 (blurry_text) - LibreOffice text blurry on Retina displays on macOS 11
Summary: LibreOffice text blurry on Retina displays on macOS 11
Status: NEW
Alias: blurry_text
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 138198 138202 138211 138216 138236 138381 138460 138565 138613 (view as bug list)
Depends on:
Blocks: HiDPI
  Show dependency treegraph
 
Reported: 2020-11-11 06:29 UTC by Alexander Barris
Modified: 2020-12-02 12:48 UTC (History)
36 users (show)

See Also:
Crash report or crash signature:


Attachments
7.0.3.1 on macOS Big Sur w/ Blurry Text (2.27 MB, image/png)
2020-11-11 06:31 UTC, Alexander Barris
Details
7.1.0.0-alpha1 on macOS Big Sur External Display (241.98 KB, image/png)
2020-11-11 06:33 UTC, Alexander Barris
Details
7.0.3.1 Calc macOS Big Sur Blurry Text (595.70 KB, image/png)
2020-11-14 02:41 UTC, Carsten
Details
Sharp Text (Selected) vs Blurry (Text) (146.90 KB, image/png)
2020-11-21 00:29 UTC, G
Details
Zoomed in screenshot of LO with the above patch (141.45 KB, image/png)
2020-12-02 12:34 UTC, Tor Lillqvist
Details
Zoomed in screenshot of NeoOffice (165.90 KB, image/png)
2020-12-02 12:37 UTC, Tor Lillqvist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Barris 2020-11-11 06:29:26 UTC
Description:
I just updated my laptop to macOS Big Sur 11.0.1 RC2 (20B28). When running LibreOffice, the bottom menu bar, font selection menu, and typed font are all blurry when using LibreOffice on the internal HiDPI Display of a MacBook Pro 13" 2020. I have experienced this in both LibreOffice 7.0.3.1 and 7.1.0.0-alpha1 but have not experienced this when running a macOS Catalina 10.15.7 partition.

Steps to Reproduce:
1. Open LibreOffice or LibreOfficeDev
2. Create new Writer Document
3. Open up Font Selector, look at bottom menu bar, or try to type text into editor

Actual Results:
The font is blurry

Expected Results:
The font should be clear


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 7.1.0.0.alpha1
Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

OpenGL

Renderer: Intel(R) Iris(TM) Plus Graphics OpenGL Engine
Vendor: Intel Inc.
Version: 4.1 INTEL-16.0.49
Device: MacBookPro16,2
Shading language version: 4.10


Max texture size: 16384 x 16384
Max vertex texture image units: 16
Max texture image units: 16
Max geometry texture units: 16
Max anisotropic filtering value: 16
Max viewport size: 16384 x 16384
Max Clip Distances: 8
Max samples: 16


Extensions: 133


GL_ARB_half_float_pixel
GL_APPLE_texture_range
GL_APPLE_vertex_point_size
GL_EXT_framebuffer_multisample_blit_scaled
GL_EXT_packed_depth_stencil
GL_EXT_texture_lod_bias
GL_EXT_provoking_vertex
GL_ARB_color_buffer_float
GL_ARB_texture_compression_rgtc
GL_ARB_draw_instanced
GL_EXT_draw_buffers2
GL_EXT_texture_shared_exponent
GL_IBM_rasterpos_clip
GL_ARB_draw_elements_base_vertex
GL_ARB_window_pos
GL_NV_depth_clamp
GL_ARB_texture_float
GL_ARB_point_parameters
GL_ARB_texture_compression
GL_EXT_transform_feedback
GL_ARB_depth_buffer_float
GL_EXT_bindable_uniform
GL_EXT_timer_query
GL_ARB_vertex_buffer_object
GL_EXT_packed_float
GL_ARB_pixel_buffer_object
GL_NV_texture_barrier
GL_APPLE_aux_depth_stencil
GL_ARB_fragment_program_shadow
GL_ARB_shading_language_100
GL_EXT_blend_func_separate
GL_ARB_texture_env_crossbar
GL_EXT_stencil_wrap
GL_ARB_transpose_matrix
GL_APPLE_vertex_array_object
GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_s3tc
GL_APPLE_packed_pixels
GL_ARB_vertex_program
GL_EXT_texture_sRGB
GL_ARB_texture_rectangle
GL_ARB_depth_clamp
GL_ARB_framebuffer_sRGB
GL_ARB_texture_env_add
GL_ARB_texture_rg
GL_ATI_texture_float
GL_EXT_texture_sRGB_decode
GL_ARB_half_float_vertex
GL_SGIS_texture_edge_clamp
GL_ARB_texture_cube_map
GL_EXT_shadow_funcs
GL_SGIS_texture_lod
GL_EXT_texture_filter_anisotropic
GL_APPLE_ycbcr_422
GL_EXT_multi_draw_arrays
GL_EXT_texture_rectangle
GL_APPLE_transform_hint
GL_ARB_shadow
GL_ARB_vertex_array_bgra
GL_ARB_shader_texture_lod
GL_SGIS_generate_mipmap
GL_EXT_blend_minmax
GL_ARB_shadow_ambient
GL_ARB_point_sprite
GL_ARB_depth_texture
GL_APPLE_row_bytes
GL_EXT_vertex_array_bgra
GL_ARB_occlusion_query
GL_ARB_fragment_shader
GL_ARB_draw_buffers
GL_ARB_texture_border_clamp
GL_EXT_clip_volume_hint
GL_APPLE_fence
GL_ARB_vertex_shader
GL_ARB_texture_mirrored_repeat
GL_EXT_fog_coord
GL_ARB_fragment_program
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_sRGB
GL_ARB_imaging
GL_ATI_separate_stencil
GL_ARB_texture_env_combine
GL_EXT_abgr
GL_EXT_bgra
GL_ARB_texture_non_power_of_two
GL_ARB_sync
GL_EXT_separate_specular_color
GL_EXT_framebuffer_object
GL_EXT_texture_integer
GL_NV_conditional_render
GL_EXT_blend_color
GL_EXT_gpu_program_parameters
GL_EXT_texture_mirror_clamp
GL_NV_texgen_reflection
GL_APPLE_vertex_program_evaluators
GL_APPLE_float_pixels
GL_NV_light_max_exponent
GL_EXT_blend_subtract
GL_EXT_gpu_shader4
GL_APPLE_element_array
GL_EXT_secondary_color
GL_APPLE_specular_vector
GL_ATI_texture_mirror_once
GL_ARB_provoking_vertex
GL_NV_blend_square
GL_EXT_draw_range_elements
GL_EXT_texture_env_add
GL_APPLE_vertex_array_range
GL_ARB_vertex_blend
GL_ATI_texture_compression_3dc
GL_APPLE_pixel_buffer
GL_ARB_multisample
GL_ARB_shader_objects
GL_EXT_geometry_shader4
GL_EXT_debug_marker
GL_ARB_texture_env_dot3
GL_APPLE_rgb_422
GL_EXT_rescale_normal
GL_EXT_blend_equation_separate
GL_EXT_debug_label
GL_ATI_texture_env_combine3
GL_APPLE_flush_buffer_range
GL_ARB_instanced_arrays
GL_APPLE_client_storage
GL_EXT_framebuffer_multisample
GL_NV_fog_distance
GL_EXT_stencil_two_side
GL_ARB_framebuffer_object
GL_EXT_depth_bounds_test
GL_ARB_multitexture
GL_EXT_texture_array
GL_ARB_seamless_cube_map
GL_APPLE_flush_render

Core features

v3.0 (100 % - 23/23)
v3.1 (100 % - 7/7)
v3.2 (100 % - 10/10)
v3.3 (100 % - 10/10)
v4.0 (100 % - 14/14)
v4.1 (100 % - 7/7)
v4.2 (0 % - 0/13)
v4.3 (0 % - 0/20)
v4.4 (0 % - 0/10)
v4.5 (0 % - 0/11)
v4.6 (0 % - 0/11)
vARB 2015 (0 % - 0/12)

OpenGL driver version check (Current: 4.1 INTEL-16.0.49, Latest known: ):
Latest version of display drivers found
According the database, you are running the latest display drivers for your video card.

Extension verification:
Comment 1 Alexander Barris 2020-11-11 06:31:33 UTC
Created attachment 167181 [details]
7.0.3.1 on macOS Big Sur w/ Blurry Text

This is using the Internal Retina HiDPI display at 1680 x 1050 (largest scale) resolution.
Comment 2 Alexander Barris 2020-11-11 06:33:29 UTC
Created attachment 167182 [details]
7.1.0.0-alpha1 on macOS Big Sur External Display

On an external display, the text is a lot less blurry when running macOS Big Sur.
Comment 3 Telesto 2020-11-11 08:09:34 UTC
Assuming the bug being present: I still wonder if switching to skia would do magic solving

- this
- They frame rate bug for HiDPI. Improved but still meh. bug 137468
- bug 138068

And might even reduce some of they macOS maintainment burden. 
See also 137468 comment 18 

However no clue how expensive this whole exercise would be in time and money
Comment 4 Alexander Barris 2020-11-13 16:29:50 UTC
Probably a HiDPI and resolution issue. When I set the internal display's resolution to 1920 x 1200, the font is clear. However, once I get it to 1680 x 1050 (Most Space), the text becomes blurry. This happens regardless of Retina (HiDPI) being enabled or disabled.
Comment 5 V Stuart Foote 2020-11-13 21:33:29 UTC
*** Bug 138198 has been marked as a duplicate of this bug. ***
Comment 6 Ming Hua 2020-11-13 22:50:55 UTC
*** Bug 138202 has been marked as a duplicate of this bug. ***
Comment 7 Carsten 2020-11-14 02:41:09 UTC
Created attachment 167293 [details]
7.0.3.1 Calc macOS Big Sur Blurry Text

I see the blurry text in 7.0.3.1 after updating to Big Sur as well.

MacBook Pro, 15.4", 2880x1800 resolution. Doesn't go away with changing the resolution.

Text that has been entered into a cell is shown blurry ("Test 1" in the attachment)
While editing a cell, the text is shown crisp ("Test 2" in the attachment)
The status line at the bottom is also blurry.

Same symptom when shifting the LibreOffice window to the sidecar display on the iPad.
Comment 8 Ming Hua 2020-11-14 11:45:16 UTC
*** Bug 138211 has been marked as a duplicate of this bug. ***
Comment 9 steve -_- 2020-11-14 18:24:40 UTC
*** Bug 138216 has been marked as a duplicate of this bug. ***
Comment 10 Arne 2020-11-14 19:36:49 UTC
The text is blurred as described on Big Sur updated 15" MacBook Pro Retina, mid-2015, 2.2 quad-core i7, standard Iris Pro graphics, but is clear and normal on updated 21.5" iMac, late-2015, 2.8 quad-core i5, Iris Pro 6200 graphics. Both Macs with release version of Big Sur, and 7.0.3.1 LibreOffice.
Comment 11 Thorsten Wagner 2020-11-14 23:57:52 UTC
First of all I am able to confirm that this issue affects Big Sur only:

macOS 10.14 Mojave:   no issue
macOS 10.15 Catalina: no issue
macOS 10.16 Big Sur:  Issue exists

Furthermore, issue seems to be present with retina displays (or 4k/5k displays) only. On standard displays I am unable to observe this issue.

There are several situations text is rendered sharp: when editing a Calc cell as mentioned above or text within widgets (buttons, combo boxes, etc.). Investigation of these situations may give a code pointer.
Comment 12 Alexander Barris 2020-11-15 02:06:03 UTC
Also experiencing this under the official macOS Big Sur 11.0.1 release (20B29).
Comment 13 gianluca.santi 2020-11-15 09:37:36 UTC
Hi,
I confirm the problem with the fonts:

macOS 10.15 Catalina + LibreOffice 7.0.0.3: no issue
macOS 10.16 Big Sur + LibreOffice 7.0.0.3 or 7.0.3:  issue exists with all  Text Document, spreadsheet, Presentation, Database....

Thanks for any help,
G.
Comment 14 Frank Fuchs 2020-11-15 11:46:02 UTC
I remember we did have this problem before with Catalina.
AFAIK - but I may be wrong - the problem got solved by updating the macos dev tool chain to the latest versions, including XCode and the sdk. 
Maybe someone can try that?
Comment 15 Emmeran Seehuber 2020-11-15 11:48:02 UTC
Please be so kind and don't add future "me too" comments. This bug (which is exact the same as bug 122218) is confirmed. It affects all macOS 11 Big Sur users with Retina screens. 

I try to recap what we know about this problem:

- It is only visible on Retina screens. It's not important if this screen is built-in or external. The fonts get blurry.
- The print preview in Calc is fine, i.e. it is *not* blurry - for what ever reason.
- macOS 10.14 added some breaking changes, which caused this bug. What this changes were exactly - no idea.
- macOS 10.14 also added some "legacy compatibility mode". If an application was build or at least pretends to be build with the SDK for macOS 10.13 or earlier, it would "revert" this breaking changes for that application. The workaround in bug 122218 made LibreOffice look like an old macOS 10.13 application. So it fixed this bug "for now".
- macOS 11 dropped this "legacy compatibility mode". So you have to adapt to the new way of doing things, or you get blurry text.

The problem is that we do not know what should be changed in LibreOffice, or what exactly the legacy stuff is LibreOffice is using, which was changed in macOS 10.14. Maybe it has something to do with the "Layer-Backed Views" described in the macOS 10.14 Release Notes 

https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes/appkit_release_notes_for_macos_10_14
 
Or maybe it's something completely different.
Comment 16 Jan-Marek Glogowski 2020-11-15 15:39:27 UTC
*** Bug 138236 has been marked as a duplicate of this bug. ***
Comment 17 Thorsten Wagner 2020-11-16 01:29:31 UTC
Additional information:

With Xcode 12.2 and latest toolchain there are further issues during build:

Xcode 12.2 / Clang 12 / SDK 10.13: build ok
Xcode 12.2 / Clang 12 / SDK 10.14: build ok
Xcode 12.2 / Clang 12 / SDK 10.15: build ok
Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok

With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails. After replacement with a workaround further errors follow. It is currently not possible to build with SDK 11.
Comment 18 Alexander Barris 2020-11-16 19:11:53 UTC
(In reply to Thorsten Wagner from comment #17)
> Additional information:
> 
> With Xcode 12.2 and latest toolchain there are further issues during build:
> 
> Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> 
> With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> After replacement with a workaround further errors follow. It is currently
> not possible to build with SDK 11.

Lovely. If you compile against other SDKs, do you experience the blurriness in macOS 11?
Comment 19 Tor Lillqvist 2020-11-16 19:52:13 UTC Comment hidden (obsolete)
Comment 20 Tor Lillqvist 2020-11-16 19:52:33 UTC
> It is currently not possible to build with SDK 11

Umm, I build LibreOffice with Xcode 12.2 using its included SDK for macOS 11 just fine? (I have never used separate SDKs.) What is it that fails for you? I use the following autogen.input:

--enable-symbols
--enable-release-build
--disable-odk
--disable-online-update
--enable-assert-always-abort
--enable-werror
--with-referenced-git=/Users/tml/lo/core
--without-export-validation
--without-java
Comment 21 Thorsten Wagner 2020-11-16 21:49:53 UTC
(In reply to Alexander Barris from comment #18)
> (In reply to Thorsten Wagner from comment #17)
> > Additional information:
> > 
> > With Xcode 12.2 and latest toolchain there are further issues during build:
> > 
> > Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> > Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> > Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> > Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> > 
> > With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> > After replacement with a workaround further errors follow. It is currently
> > not possible to build with SDK 11.
> 
> Lovely. If you compile against other SDKs, do you experience the blurriness
> in macOS 11?

Yes, as Emmeran wrote above: Issue is reproducible with all SDKs on Big Sur. Currently LO is patched to appear as 10.13 application. I am trying to build LO without patch as 11 application.
Comment 22 Thorsten Wagner 2020-11-16 21:50:36 UTC
(In reply to Tor Lillqvist from comment #20)
> > It is currently not possible to build with SDK 11
> 
> Umm, I build LibreOffice with Xcode 12.2 using its included SDK for macOS 11
> just fine? (I have never used separate SDKs.) What is it that fails for you?
> I use the following autogen.input:
> 
> --enable-symbols
> --enable-release-build
> --disable-odk
> --disable-online-update
> --enable-assert-always-abort
> --enable-werror
> --with-referenced-git=/Users/tml/lo/core
> --without-export-validation
> --without-java

Thank you; will doublecheck my toolchain
Comment 23 Alexander Barris 2020-11-17 01:12:07 UTC
(In reply to Thorsten Wagner from comment #21)
> (In reply to Alexander Barris from comment #18)
> > (In reply to Thorsten Wagner from comment #17)
> > > Additional information:
> > > 
> > > With Xcode 12.2 and latest toolchain there are further issues during build:
> > > 
> > > Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> > > Xcode 12.2 / Clang 12 / SDK 10.14: build ok
> > > Xcode 12.2 / Clang 12 / SDK 10.15: build ok
> > > Xcode 12.2 / Clang 12 / SDK 11:    build NOT ok
> > > 
> > > With SDK 11 configure macro AC_CHECK_SIZEOF used in configure.ac fails.
> > > After replacement with a workaround further errors follow. It is currently
> > > not possible to build with SDK 11.
> > 
> > Lovely. If you compile against other SDKs, do you experience the blurriness
> > in macOS 11?
> 
> Yes, as Emmeran wrote above: Issue is reproducible with all SDKs on Big Sur.
> Currently LO is patched to appear as 10.13 application. I am trying to build
> LO without patch as 11 application.

I also want to take a look at this. Where can you find the build instructions? I tried looking at the DocumentFoundation wiki, but the instructions look quite old.
Comment 24 Emmeran Seehuber 2020-11-17 07:30:20 UTC
(In reply to Alexander Barris from comment #23)
> I also want to take a look at this. Where can you find the build
> instructions? I tried looking at the DocumentFoundation wiki, but the
> instructions look quite old.
See here:
https://wiki.documentfoundation.org/Development/lode

If you use MacPorts, you must ensure that it is not in the $PATH. If you sign your git commits using gpg, you should disable that, because gettext at least for me fails to build in that case. I've made myself a "env.sh", which sets that stuff up for me. I "source env.sh" before I try to build LibreOffice.

It looks like this for me:

export GIT_CONFIG_NOSYSTEM=1
export LODE_HOME=/your/path/to/lode
export PATH=$LODE_HOME/opt/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/MacGPG2/bin:/Library/Apple/usr/bin

Note: You need at least 95 GB to build LibreOffice with debug symbols. So you may, like I do, build it on a external drive.

After lode did checkout the source, before calling autogen.sh, you should edit dev/core/autogen.input and put something like this in it:

--enable-debug
--enable-symbols
--disable-odk
--disable-online-update
--enable-assert-always-abort
--without-export-validation
--without-java
--without-doxygen
--enable-python=no
Comment 25 Tor Lillqvist 2020-11-17 07:51:00 UTC
@Emmeran (and others), please, feel free to update the Wiki, to make it more relevant for newcomers.

But yeah, in my humble opinion, things would be a lot simpler if there would just be consensus to stop requiring Java by default, and stop building the ODK by default. Then at least the --without-java and --disable-odk switches wouldn't be needed to get started in a simple fashion.
Comment 26 lupurus 2020-11-17 09:37:36 UTC
I could compile it with "--without-java --without-doxygen" with Xcode 12.2 on Big Sur and without modifying the code. There are no changes, the text is still blurred. I will later try to have a look at the patch: https://git.libreoffice.org/core/+/ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21


And by the way: It's unfortunately not very beginner friendly, I was surprised, that I could manage to build it. But everything else seems to be a black hole for me, I have no clue where to start ;)
Comment 27 Emmeran Seehuber 2020-11-17 10:57:04 UTC
(In reply to lupurus from comment #26)
> I could compile it with "--without-java --without-doxygen" with Xcode 12.2
> on Big Sur and without modifying the code. There are no changes, the text is
> still blurred. I will later try to have a look at the patch:
> https://git.libreoffice.org/core/+/
> ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21

This patch won't help, because this patch only makes LibreOffice look like an old application built against a version 0 of the SDK. As said, Big Sur removed their compatibility with this. This patch only helps with macOS 10.15 or earlier.
Comment 28 Christian Lohmaier 2020-11-17 12:42:02 UTC
(In reply to Thorsten Wagner from comment #17)
> Additional information:
> 
> With Xcode 12.2 and latest toolchain there are further issues during build:
> 
> Xcode 12.2 / Clang 12 / SDK 10.13: build ok
> […]

Note that release builds are done on macOS 10.14 with XCode 11  with deployment target/minimum-version-required of 10.10 and against the 10.15 SDK with API features limited to 10.15 (MAC_OS_X_VERSION_MAX_ALLOWED)
Comment 29 Thorsten Wagner 2020-11-17 13:47:32 UTC
Confirming Emmerans evaluation: Blurry text with SDK 11 too. Issue is the same as on macOS 10.14 and 10.15 without patch (or without compiling against SDK 10.13). Mix of sharp and blurry text depending on the situation is present on macOS 10.14 and 10.15 without patch too.

To sum up: Starting with Big Sur there is no longer a workaround and issue has to be resolved now - no need to modify build baselines.
Comment 30 Mike Kaganski 2020-11-17 14:25:54 UTC
An offtopic.

(In reply to Emmeran Seehuber from comment #24)
> Note: You need at least 95 GB to build LibreOffice with debug symbols. So
> you may, like I do, build it on a external drive.
> ...
> --enable-debug
> --enable-symbols

Don't those configures put symbols into binaries *and also* in the separate symbol files, maybe doubling space requirement? (I may be wrong...)
Comment 31 lupurus 2020-11-17 14:47:37 UTC
(In reply to Thorsten Wagner from comment #29)
> Confirming Emmerans evaluation: Blurry text with SDK 11 too. Issue is the
> same as on macOS 10.14 and 10.15 without patch (or without compiling against
> SDK 10.13). Mix of sharp and blurry text depending on the situation is
> present on macOS 10.14 and 10.15 without patch too.
> 
> To sum up: Starting with Big Sur there is no longer a workaround and issue
> has to be resolved now - no need to modify build baselines.

Ok thanks, then I don't need to take it look inside this ;)

Is there any documentation about the different source folders? Where could one start? (I don't mean it just specifically for this kind of bug, I'm thinking about trying to improve some stuff for the macOS port)
Comment 32 Mike Kaganski 2020-11-17 14:59:22 UTC
(In reply to lupurus from comment #31)
> Is there any documentation about the different source folders?

Please check READMEs in the top-level folders, like sal, vcl, sw. Also there's a "Code Overview" link available on the root Development wiki page [1].

[1] https://wiki.documentfoundation.org/Development
Comment 33 lupurus 2020-11-17 17:14:50 UTC
Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15

The text is still blurred, but I'm wondering, because setting the SDK to > 10.14 should change more things, for example that the window will adapt to the dark mode.
Comment 34 Telesto 2020-11-17 17:24:12 UTC
(In reply to lupurus from comment #33)
> Is there any documentation about the different source folders? Where could
> one start? (I don't mean it just specifically for this kind of bug, I'm
> thinking about trying to improve some stuff for the macOS port)

Searching for mm extension or looking into osx/aqua directories quite good pointer of macOS specific code

https://opengrok.libreoffice.org/xref/core/vcl/osx/

And for documentation: https://wiki.openoffice.org/wiki/Category:MacOSX
It's old and not up-to-date, but should still contain some relevant info
Comment 35 Thorsten Wagner 2020-11-17 17:36:15 UTC
(In reply to lupurus from comment #33)
> Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk
> --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15
> 
> The text is still blurred, but I'm wondering, because setting the SDK to >
> 10.14 should change more things, for example that the window will adapt to
> the dark mode.

LO is patched at the end of the build process to behave as 10.13 application independent of the SDK in use. Beside avoiding blurred text on macOS < 11 dark mode is disabled. For now this is eligible as dark mode implementation is very incomplete - better to stay on light mode as enabling an incomplete dark mode, e.g. on systems which switch between dark and light mode automatically.

As a complete or at least a sufficient dark mode implementation is another change, fixing this bug should result in a still disabled dark mode.
Comment 36 lupurus 2020-11-17 18:19:03 UTC
(In reply to Thorsten Wagner from comment #35)
> (In reply to lupurus from comment #33)
> > Thanks. It's interesting. I tried: ./autogen.sh --without-java --disable-odk
> > --with-macosx-sdk=11.0 --with-macosx-version-min-required=10.15
> > 
> > The text is still blurred, but I'm wondering, because setting the SDK to >
> > 10.14 should change more things, for example that the window will adapt to
> > the dark mode.
> 
> LO is patched at the end of the build process to behave as 10.13 application
> independent of the SDK in use. Beside avoiding blurred text on macOS < 11
> dark mode is disabled.

Where can I find that patch? You can opt out for the dark mode so long: https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app#2993818
Comment 37 lupurus 2020-11-17 18:33:48 UTC
I found this:

https://stackoverflow.com/questions/4779507/font-issue-with-layer-backed-nstextview

https://stackoverflow.com/questions/3917871/creating-a-label-using-nstextfield-is-blurry

I tried to set this in salframe.cxx, but no changes:

mpNSView.layerContentsRedrawPolicy = NSViewLayerContentsRedrawDuringViewResize;
mpNSView.wantsLayer = 0;

Unfortunately I couldn't find out until now, where LO is drawing the text on the view.

Maybe I should give up searching for this, I'm too much used to Swift right now. If someone more experienced want to help me, please contact me via mail (in english or german)
Comment 38 Tor Lillqvist 2020-11-17 21:39:06 UTC
> Where can I find that patch?

The patch in question is this change that was made to the LibreOffice source coce in February: https://git.libreoffice.org/core/+/ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21

The relevant part is the change to desktop/Executable_soffice_bin.mk that causes some more flags to be used when linking the soffice executable (which is the actual executable of the LibreOffice app bundle):

> -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0

which in practice, if you use the default minimum required macOS version of 10.10, expands to:

> -Xlinker -platform_version -Xlinker macos -Xlinker 10.10 -Xlinker 0.0.0

which means that the actual extra flags passed to ld are:

>  -platform_version macos 10.10 0.0.0

See the ld(1) man page for what that means.

To see this in practice, in an already-built LibreOffice tree, do:

> rm instdir/LibreOfficeDev.app/Contents/MacOS/soffice
> make verbose=t desktop
Comment 39 lupurus 2020-11-18 07:08:51 UTC
(In reply to Tor Lillqvist from comment #38)
> > Where can I find that patch?
> 
> The patch in question is this change that was made to the LibreOffice source
> coce in February:
> https://git.libreoffice.org/core/+/
> ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21
> 
> The relevant part is the change to desktop/Executable_soffice_bin.mk that
> causes some more flags to be used when linking the soffice executable (which
> is the actual executable of the LibreOffice app bundle):
> 
> > -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0

Thank you! Actually I removed those lines, but otool still showed me the min version of 10.10 and sdk n/a. 

So I changed the header with an hex editor, so that I have 

cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.15
      sdk 11.0

The app now started in the dark mode, so I know, that it uses the new SDK. There are no changes, the text is still blurred. I will take a closer look to the text drawing methods, because I also figured out, that the text in a Combobox for example is blurred as well. But I will need a lot of time to get an overview, how all this drawing works (maybe in the end I can at least help improving the dark mode :))
Comment 40 Alexander Barris 2020-11-18 14:59:59 UTC
(In reply to lupurus from comment #39)
> (In reply to Tor Lillqvist from comment #38)
> > > Where can I find that patch?
> > 
> > The patch in question is this change that was made to the LibreOffice source
> > coce in February:
> > https://git.libreoffice.org/core/+/
> > ec9f0161d9b5a57d4b8e3e17150fabcc6e4c67a1%5E%21
> > 
> > The relevant part is the change to desktop/Executable_soffice_bin.mk that
> > causes some more flags to be used when linking the soffice executable (which
> > is the actual executable of the LibreOffice app bundle):
> > 
> > > -Xlinker -platform_version -Xlinker macos -Xlinker $(MAC_OS_X_VERSION_MIN_REQUIRED_DOTS) -Xlinker 0.0.0
> 
> Thank you! Actually I removed those lines, but otool still showed me the min
> version of 10.10 and sdk n/a. 
> 
> So I changed the header with an hex editor, so that I have 
> 
> cmd LC_VERSION_MIN_MACOSX
>   cmdsize 16
>   version 10.15
>       sdk 11.0
> 
> The app now started in the dark mode, so I know, that it uses the new SDK.
> There are no changes, the text is still blurred. I will take a closer look
> to the text drawing methods, because I also figured out, that the text in a
> Combobox for example is blurred as well. But I will need a lot of time to
> get an overview, how all this drawing works (maybe in the end I can at least
> help improving the dark mode :))

I mean, fixing Dark Mode rocks. How does it look? Does LO need updating in order for it to look correct? You can post your work here too:
https://bugs.documentfoundation.org/show_bug.cgi?id=118017
Comment 41 Telesto 2020-11-18 15:28:21 UTC Comment hidden (off-topic)
Comment 42 Tor Lillqvist 2020-11-18 16:27:20 UTC
OK. Well I'm out then.
Comment 43 Samuel Mehrbrodt (CIB) 2020-11-18 16:43:46 UTC
(In reply to Telesto from comment #41)
> Solving this particular problem maybe not the best investment. Even if this
> would solve the issue here. 

Please don't keep contributors from working on what they think is worth it. Thanks!
Comment 44 Telesto 2020-11-18 19:35:59 UTC Comment hidden (spam)
Comment 45 Alexander Barris 2020-11-18 22:33:09 UTC
So what areas/files need to be changed/fixed in order to tackle this bug? I don't know ANY Objective-C so unfortunately I won't be much help with the code, but can help build and test when changes are made to the source.
Comment 46 Thorsten Wagner 2020-11-18 23:04:05 UTC
I will take a look at the code during the next few days to isolate some code pointers...

BTW: Please let us discuss only the issue related technical details here. As LO has a good visual appearance on macOS and becomes significantly worse on Big Sur, this issue has do be fixed independent of long term considerations.
Comment 47 lupurus 2020-11-19 07:23:03 UTC
I'm sorry for drifting away a little bit with my comments about dark mode and so on. Thats just because I am new to the code base and I'm trying to understand, how the things work, so that I maybe can find a solution for this issue (this has the first priority).

As far as I understand it right now, LO is drawing everything in a NSView, it doesn't uses the native widgets of Cocoa (what would explain, that it's not that performant as a native application). But it still uses drawing methods from the Carbon framework? If so, I don't think, that Skia will help here in any way, because using the native drawing code of Apple will be necessary either way for drawing the components.
Comment 48 Telesto 2020-11-19 09:31:54 UTC
(In reply to lupurus from comment #47)
> But it still uses drawing methods from the Carbon framework? 

As far i'm aware, yes. MacOS code isn't refactored since the OoO day's, so.
Comment 49 Tor Lillqvist 2020-11-19 10:15:01 UTC
Please explain what you actually mean with "Carbon". The code uses CoreGraphics, does that count as "Carbon"?
Comment 50 Tor Lillqvist 2020-11-19 10:21:30 UTC
Note that the LibreOffice codebase is even worse in its choice of names, it uses the term "Aqua" in identifiers as if Aqua was some API. Maybe it was a name loosely used at some point in time in the history of macOS, but it sure hasn't been an API name a long time. If one searches for "aqua" in Xcode's Developer Documentation, nothing is found.

If one searches for "carbon", it does show some legacy APIs that Apple classifies as being "Carbon", but the functions listed as part of "Carbon Core" don't look familiar at all. And they seem to have been obsoleted since a long time, and we do have warnings for obsolete APIs turned on, so I think I can say with reasonable confidence that no, we don't use "Carbon". If somebody has concrete counter-evidence I am prepared to change that opinion, of course.
Comment 51 Thorsten Wagner 2020-11-19 10:43:37 UTC
(In reply to lupurus from comment #47)
> I'm sorry for drifting away a little bit with my comments about dark mode
> and so on. Thats just because I am new to the code base and I'm trying to
> understand, how the things work, so that I maybe can find a solution for
> this issue (this has the first priority).
> 
> As far as I understand it right now, LO is drawing everything in a NSView,
> it doesn't uses the native widgets of Cocoa (what would explain, that it's
> not that performant as a native application). But it still uses drawing
> methods from the Carbon framework? If so, I don't think, that Skia will help
> here in any way, because using the native drawing code of Apple will be
> necessary either way for drawing the components.

For most tasks Cocoa calls are used (e.g. CoreText). Exception are GUI widgets: As the Cocoa document model is not used by LO, these are drawn using Carbon (HIWidgets). Text within these widgets is rendered by separate CoreText calls from LO code. This approach was common during the Carbon days and has been choosen to be consistent with the other GUI implementations (GTK, QT, Windows). It would be a major change to replace this with many implications to the other GUI implementations and should be not in the scope of this issue.

As a first step I suggest to look at combo boxes: Text within is sharp (CoreText). Text within dropdown lists is blurry. It has to be investigated if text within dropdown boxes is rendered by CoreText too (which I would expect) or if it is rendered by another kind of font rendering (which should be not the case).
Comment 52 lupurus 2020-11-19 11:16:52 UTC
(In reply to Thorsten Wagner from comment #51)
> For most tasks Cocoa calls are used (e.g. CoreText). Exception are GUI
> widgets: As the Cocoa document model is not used by LO, these are drawn
> using Carbon (HIWidgets). Text within these widgets is rendered by separate
> CoreText calls from LO code. This approach was common during the Carbon days
> and has been choosen to be consistent with the other GUI implementations
> (GTK, QT, Windows). It would be a major change to replace this with many
> implications to the other GUI implementations and should be not in the scope
> of this issue.
> 

Yes, this is what I found out so far. It uses the drawing methods HI.... This is part of the Carbon.framework, that was before Cocoa. Interestingly, it still works and it isn't a problem for this issue (it will be, if Apple will remove those drawing methods one day).

If you look at the code, you can see, that the Combobox itself gets drawed by this HIThemeDrawButton method. There the text is clear. The problem is the popup area and this is not drawn with this methods (I could not find out yet, where the area gets drawed). You can see it as well here: https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls#ComboBox

They write, that the area is not native.
Comment 53 Thorsten Wagner 2020-11-19 11:33:18 UTC
(In reply to lupurus from comment #52)
> If you look at the code, you can see, that the Combobox itself gets drawed
> by this HIThemeDrawButton method. There the text is clear. The problem is
> the popup area and this is not drawn with this methods (I could not find out
> yet, where the area gets drawed). You can see it as well here:
> https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls#ComboBox

HIThemeDrawButton draws the graphical outline of a button only. There is no text rendering within HIThemeDrawButton. Text is placed within button by another CoreText call from the surrounding LO code.
Comment 54 Tor Lillqvist 2020-11-19 11:59:43 UTC
Ah, yes, that old "native widget" thing. (I.e. controls that aren't *native* at all, just try to look "native".

If I recall correctly, what HIThemeDrawButton draws is just an image of how a button should look, and that image is then used to draw the actual button images in the dialogs. Possibly it could be replaced with something that draws a NSButton instead into an image. But in both cases, this will not make the buttons actually *behave* like real native buttons should.

But yeah, the ideal would obviously be to use so-called welded controls, like LibreOffice does on gtk3. Then we would have truly native controls.

But anyway, native or not-so-native controls have little to do with what *this* bug is about, surely?
Comment 55 lupurus 2020-11-19 12:36:04 UTC
(In reply to Tor Lillqvist from comment #54)
> But yeah, the ideal would obviously be to use so-called welded controls,
> like LibreOffice does on gtk3. Then we would have truly native controls.

This would be perfect, but I guess a lot of work ;)

> But anyway, native or not-so-native controls have little to do with what
> *this* bug is about, surely?

If it would be native controls, the text would not be blurry. But for now, the big question is: Where is the text in the popup area and all the other areas get drawed?
Comment 56 Tor Lillqvist 2020-11-19 12:50:09 UTC
Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx, as far as I recall. Look for the CTFontDrawGlyphs() call.
Comment 57 lupurus 2020-11-20 06:25:20 UTC
(In reply to Tor Lillqvist from comment #56)
> Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> as far as I recall. Look for the CTFontDrawGlyphs() call.

Thank you. I am kind of frustrated right now, I tried a lot of different settings like 'CGContextSetAllowsFontSmoothing' for example... nothing helped. I am still wondering: Why is the font in the main view, the status bar, the combobox area blurred, but the text in the TOC or where you can select the text styles for example or in other menus not? Are they using different methods?
Comment 58 Telesto 2020-11-20 07:58:56 UTC
(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.
> 
> Thank you. I am kind of frustrated right now, I tried a lot of different
> settings like 'CGContextSetAllowsFontSmoothing' for example... nothing
> helped. I am still wondering: Why is the font in the main view, the status
> bar, the combobox area blurred, but the text in the TOC or where you can
> select the text styles for example or in other menus not? Are they using
> different methods?

Not having Big Sur installed, yet (and kind a reluctant to do so). So not having much to go on.. based on screenshots tend say that they stuff is painted as an image at low resolution (72/96 dpi) (without prior anti-aliasing)

Bit like saving QR code into DOCX format (and file reload). They SVG rendering simply quality simply bad (looks like miniature thumbnail quality being over-sized). And File -> Export formats do have also a bad ugly compression flaw somewhere. But surely depends on code paths :-( So not all export formats are affected 

And also which branch did you use? Master or 7.0? There where more code changes also related to anti-aliasing and image rendering (see Skia meta). Not sure if they his code simply limited to Skia or having large reach.

If so, bugs might have stacked up (worst case)? I assume you build without or include they Stephan hack while nobody actually has clue what it does? As it did work previously?

Also there is a risk that Apple dropped support for XYZ in Big Sur (or didn't notice they broke some legacy stuff nobody supposed to use anymore). So maybe Catalina without Stephan Bergmans patch? Not even remembering when/how the initial bug started. Except they Xcode magic an later-on they hack?

Note: only few things crossing my mind :-). Not saying it's of any use. However prefer to exclude some possibility's. Or might open a different perspective. 

Anyhow thanks for attempting for solving the mystery :-)
Comment 59 Emmeran Seehuber 2020-11-20 08:20:52 UTC
(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.
> 
> Thank you. I am kind of frustrated right now, I tried a lot of different
> settings like 'CGContextSetAllowsFontSmoothing' for example... nothing
> helped. I am still wondering: Why is the font in the main view, the status
> bar, the combobox area blurred, but the text in the TOC or where you can
> select the text styles for example or in other menus not? Are they using
> different methods?

I don't think that the problem is related to the way the text is painted, as it not only affects text, but also lines. Just open a Draw document and do some diagonal lines. You'll see that they are blurry also, but it's not that visible and apparent as it is with text. 

The AquaSalGraphics have the right scaling for their CGLayer used (i.e. fScale is 2 for retina in AquaSalGraphics::CheckContext()). For me it seems that all drawing on this CGLayer is done with a 0.5 scale and the final copy to the parent CGContext is done with a 2 scale (i.e. to compensate the 0.5 scale while drawing). I found an Object-C snippet that should allow to export a CGLayer into a PNG to valid it's contents (https://stackoverflow.com/questions/525609/use-c-with-cocoa-instead-of-objective-c), but as I have no clue about Objective-C I can not integrate that. Is there any other way to inspect whats in a CGLayer?
Comment 60 Jan-Marek Glogowski 2020-11-20 20:56:49 UTC
*** Bug 138381 has been marked as a duplicate of this bug. ***
Comment 61 G 2020-11-21 00:29:36 UTC
Created attachment 167439 [details]
Sharp Text (Selected) vs Blurry (Text)

The issue is now with BigSur, it was fixed before in Catalina with a patch.
I would say that is a new issue as with the same Libreoffice 6.4.7.2, before the Update the fonts where all right, and after the MacOs update to BigSur, the same version of Libreoffice 6.4.7.2 and Libreoffice 7.0.3.1 are Blurry.
Comment 62 Mike Kaganski 2020-11-24 13:19:12 UTC
*** Bug 138460 has been marked as a duplicate of this bug. ***
Comment 63 Telesto 2020-11-24 14:14:32 UTC
(In reply to lupurus from comment #57)
> (In reply to Tor Lillqvist from comment #56)
> > Text is drawn in AquaSalGraphics::DrawTextLayout() in vcl/quartz/salgdi.cxx,
> > as far as I recall. Look for the CTFontDrawGlyphs() call.

Only a some old info which hidden in bug 122218

They temporal - now broken hack - for Catalina (instead they temporal solution of building with Xcode 10)
https://gerrit.libreoffice.org/c/core/+/88667/2/desktop/Executable_soffice_bin.mk

See additional comments/explanation for they old hack: 
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c190
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c194

---
FWIW: does tinkering with TinkerTool related to font make any difference? Only a thought.. There is an option or old style font rendering. There is bug report about font not being 'crisp' but kind of different of being blurry. So who knows...
Comment 64 Telesto 2020-11-24 14:18:51 UTC
And is this still being true?
https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c203
Comment 65 Aron Budea 2020-11-25 01:38:37 UTC
I'm assuming the same severity/priority as bug 122218 is warranted here.
Comment 66 Jean 2020-11-27 16:16:21 UTC
(In reply to Alexander Barris from comment #4)
> Probably a HiDPI and resolution issue. When I set the internal display's
> resolution to 1920 x 1200, the font is clear. However, once I get it to 1680
> x 1050 (Most Space), the text becomes blurry. This happens regardless of
> Retina (HiDPI) being enabled or disabled.

No clear improvement when modifying resolution.
We do not find the previous clarity.
I remember this happened in the same way when moving from version 5.x to version 6.

Quite annoying...
Comment 67 Jean 2020-11-27 16:22:07 UTC
Version 7.0.3.1 on macOS Catalina was OK

Version 7.0.3.1 on masOS Big Sur NOT OK
Version 7.1.0.0.0beta1 onmasOS Big Sur NOT OK
Comment 68 Jean 2020-11-27 17:06:43 UTC
On top of that, all other Mac-compatible softwares tested (so far) do not show such defect.
Moving from Version 5 to Version 6, only LibreOffice had such problem.

Just loaded OpenOffice 4.1.8. and it works perfect...
Comment 69 Tor Lillqvist 2020-11-27 17:07:45 UTC
Feel free to use Apache OpenOffice then, we won't mind!
Comment 70 Mugs 2020-11-27 22:19:44 UTC
(In reply to Tor Lillqvist from comment #69)
> Feel free to use Apache OpenOffice then, we won't mind!

I have already done that, and as stated the interface is clear and beautiful as you would expect on a Retina display - however for some reason, certain images embedded in the files do not display. For this reason I have had to shell out dollars to pay for NeoOffice which in my opinion is still far inferior to LibreOffice, but fixes the blurring issue. Can the solution to the problem in LibreOffice not be gleaned from why OpenOffice and NeoOffice do not suffer from this problem - I would so desperately like to return to LibreOffice
Comment 71 Tor Lillqvist 2020-11-27 22:34:00 UTC
No, the codebase of those is so different that it doesn't help much. Plus in the NeoOffice case, its license makes it impossible.
Comment 72 Telesto 2020-11-27 22:42:30 UTC
Out of curiosity -  based on they assumption OoO working correctly... is there a working version in they LibreOffice archive.. 

https://downloadarchive.documentfoundation.org/libreoffice/old/

If so, maybe in a bibisecting range?
https://wiki.documentfoundation.org/QA/Bibisect/macOS
Comment 73 Alexander Barris 2020-11-27 23:18:20 UTC
(In reply to Telesto from comment #72)
> Out of curiosity -  based on they assumption OoO working correctly... is
> there a working version in they LibreOffice archive.. 
> 
> https://downloadarchive.documentfoundation.org/libreoffice/old/
> 
> If so, maybe in a bibisecting range?
> https://wiki.documentfoundation.org/QA/Bibisect/macOS

I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of LibreOffice should be tested?
Comment 74 Telesto 2020-11-28 07:48:20 UTC
(In reply to Alexander Barris from comment #73)
> I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of
> LibreOffice should be tested?

Not having really systematic approach, but lets say
https://downloadarchive.documentfoundation.org/libreoffice/old/5.0.0.5/mac/x86_64/

if that one is also bad
https://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.4/mac/x86_64/ (there are no older x64 builds..)

if 5.0.0.5 being good, take 6.0.0.3
Comment 75 Alexander Barris 2020-11-28 17:30:42 UTC
(In reply to Telesto from comment #74)
> (In reply to Alexander Barris from comment #73)
> > I can confirm the latest OpenOffice 4.1.8 works fine. Which old version of
> > LibreOffice should be tested?
> 
> Not having really systematic approach, but lets say
> https://downloadarchive.documentfoundation.org/libreoffice/old/5.0.0.5/mac/
> x86_64/
> 
> if that one is also bad
> https://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.4/mac/
> x86_64/ (there are no older x64 builds..)
> 
> if 5.0.0.5 being good, take 6.0.0.3

6.1.0.1, 5.0.0.5, and 4.2.0.4 mysteriously segfaulted for me....
Comment 76 trainman75 2020-11-28 23:50:56 UTC
(In reply to Jean from comment #68)
> On top of that, all other Mac-compatible softwares tested (so far) do not
> show such defect.
> Moving from Version 5 to Version 6, only LibreOffice had such problem.
> 
> Just loaded OpenOffice 4.1.8. and it works perfect...

I've found certain areas within Audacity do the same - drop down menus are clear, other text is blurry. 

Doesn't help here, but LO is not alone!
Comment 77 Jean 2020-11-30 11:01:14 UTC
(In reply to Tor Lillqvist from comment #69)
> Feel free to use Apache OpenOffice then, we won't mind!

I am too faithful for that... I have one computer on Black Sur, but that is a demonstration tool for secondary work, my main unit is still on Catalina, and I will not move till the solution has been brought.

There is a slight improvement by doing this in Terminal:

1. defaults -currentHost write -g AppleFontSmoothing -int 0 
2. reboot

I followed the instructions on this link which recommends to proceed to steps 3. and 4. but when I do that, I again find the defect.

With Steps 1 and 2, it is a little better (at least, one can work in better conditions.

https://discussions.apple.com/thread/252034861
Comment 78 Xisco Faulí 2020-11-30 11:49:27 UTC
*** Bug 138565 has been marked as a duplicate of this bug. ***
Comment 79 Tor Lillqvist 2020-11-30 19:47:02 UTC
Btw, for some experimentation code, see https://bugs.documentfoundation.org/show_bug.cgi?id=122218#c219 .

(In general, for anybody seriously pondering investigating and fixing this, it probably is a good idea to read through that bug, but yeah, not all comments are very informative.)
Comment 80 Alexander Barris 2020-12-01 05:12:37 UTC Comment hidden (me-too)
Comment 81 Tor Lillqvist 2020-12-01 06:42:16 UTC Comment hidden (off-topic)
Comment 82 Tor Lillqvist 2020-12-01 09:23:54 UTC
Technical details: What apparently is going on is that in macOS 10.14 and 10.15, views (NSView objects) were backed by a Core Animation layer if the app was built against the 10.14 SDK or later.

What Stephan Bergmann's patch (645fe53be0dc36535dba0ed684e21ca4cda80d70) does is to make the soffice binary marked as built against some unknown old SDK even if it was built with a current Xcode.

But in macOS 11.0, views are always backed by Core Animation layer, the SDK version of the program executable does not matter any longer. (This is nicely summarised by the commit message (unrelated to LibreOffice) in https://codereview.qt-project.org/c/qt/qtbase/+/322228 , for instance.)
Comment 83 J-M Allier 2020-12-01 18:30:31 UTC
I upgraded my MacBook Pro to macOS Big Sur 11.0.1 and then LibreOffice from 6.4.7.2 to 7.0.3. The characters were blurry on 6.4.7.2 and on 7.0.3 as well. Because of other bugs on 7.0.3 I reverted to 6.4.7.

I have done some tests with OpenOffice 4.1.8, NeoOffice 2017.23 and, unfortunately with LO6472, but I believe it gave interesting results. I hope this will help to solve the bug.

I used an external 1920*1080 HD screen connected by HDMI to the MacBook Pro.

First I set the main display to the Retina display and compared characters with the same file (an ods file) on the three apps. Moving windows from the main to the secondary and back to main display. The characters were crisp on the Retina display with NeoOffice and OpenOffice. Blurry in LO.

Then I set the main display to the external display (1920*1080). 

Of course, LO characters were blurry on the Retina display. 
But a difference appeared between OO and NO when windows were moved to the Retina display. NeoOff displayed crisp characters on Retina, but OpenOff displayed the same blurry characters as LO. 

Maybe this will give some clues.
Comment 84 Ming Hua 2020-12-01 23:07:42 UTC
*** Bug 138613 has been marked as a duplicate of this bug. ***
Comment 85 Jan-Marek Glogowski 2020-12-02 02:40:20 UTC
After reading comment 82, I was curious and downloaded the NeoOffice source, which - according to their marketing and comment 83 - works correct w.r.t. "crisp fonts" on MacOS 11 / Big Sur.

An "grep -ri" over the whole NeoOffice codebase for either CALayer or wantsLayer returns no hits, which IMHO strongly suggests, that the whole CALayer problem fixed by Qt mentioned in comment 82 is not the same problem LO has. If you read the original QT bug reference in the commit (https://bugreports.qt.io/browse/QTBUG-87014), you'll find that Qt has application startup problems and nothing in the bug's comments indicate anything else.

So I really doubt LO needs any adoption regarding CALayer handling.

Now for a different idea about the origin of the bug: my assumption is, that all this is "just" some scaling problem originating in the way Retina screens are handled in MacOS graphics layer. And IMHO a very strong indicator for a problem is commit 7c35d5f0669f461254668c1854291e1324b37c21. I introduced that assert and never saw it failing; but then I never had any Retina HW. And problems might have originally started with macOS 10.14, when commit e659c6a1857fbb8e5a6e8ff60fe241483eea32dd as a workaround, which converted the bitmap context for headless LO into a generic fallback. AFAIK this was introduced for https://bz.apache.org/ooo/show_bug.cgi?id=91990

And maybe my commit b14371703236160bf34480ef831e9b2244e140ee back then just made things worse.

My suggestion would be to revert commit 7c35d5f0669f461254668c1854291e1324b37c21 to see, if LO still triggers that assert and try to find out, why commit e659c6a1857fbb8e5a6e8ff60fe241483eea32dd is needed at all.

BTW: there is CGContextGetUserSpaceToDeviceSpaceTransform or CGContextConvertSizeToDeviceSpace, which could indicate some wrong mapping resulting in scaled text.

P.S. I don't have any mac HW, so I can't test myself.
Comment 86 Tor Lillqvist 2020-12-02 12:25:06 UTC Comment hidden (spam)
Comment 87 Tor Lillqvist 2020-12-02 12:25:38 UTC
Using ideas from the experimentation patch mentioned in comment #39, I think I see a clear improvement when using some combination of the tweaks from that, like:

diff --git a/vcl/quartz/salgdi.cxx b/vcl/quartz/salgdi.cxx
index 704bba1fae9c..23f93aeb9272 100644
--- a/vcl/quartz/salgdi.cxx
+++ b/vcl/quartz/salgdi.cxx
@@ -450,7 +450,16 @@ void AquaSalGraphics::DrawTextLayout(const GenericSalLayout& rLayout)
 
     // The view is vertically flipped (no idea why), flip it back.
     CGContextScaleCTM(maContextHolder.get(), 1.0, -1.0);
-    CGContextSetShouldAntialias(maContextHolder.get(), !mbNonAntialiasedText);
+
+    CGContextSetShouldAntialias(maContextHolder.get(), true);
+    CGContextSetAllowsAntialiasing(maContextHolder.get(), true);
+    CGContextSetAllowsFontSmoothing(maContextHolder.get(), false);
+    CGContextSetShouldSmoothFonts(maContextHolder.get(), false);
+    CGContextSetAllowsFontSubpixelPositioning(maContextHolder.get(), true);
+    CGContextSetShouldSubpixelPositionFonts(maContextHolder.get(), true);
+    CGContextSetAllowsFontSubpixelQuantization(maContextHolder.get(), true);
+    CGContextSetShouldSubpixelQuantizeFonts(maContextHolder.get(), true);
+
     CGContextSetFillColor(maContextHolder.get(), maTextColor.AsArray());
 
     if (rStyle.mbFauxBold)

But if I zoom in a lot, I see that the text is still rendered much different than in NeoOffice, for instance.
Comment 88 Tor Lillqvist 2020-12-02 12:34:45 UTC
Created attachment 167757 [details]
Zoomed in screenshot of LO with the above patch

As can be seen, the letters are quite grey, you don't see many fully black pixels at all.
Comment 89 Tor Lillqvist 2020-12-02 12:37:55 UTC
Created attachment 167758 [details]
Zoomed in screenshot of NeoOffice

Very crisp and black letters.
Comment 90 Tor Lillqvist 2020-12-02 12:42:19 UTC
Anyway, my guess is that it is not through some combination of CGContextSet* calls that affect text rendering that we should fix this problem, but that indeed there is something fundamentally wrong or unnecessarily complex in how the text is rendered and eventually ends up on the screen. At some stage the rendered text perhaps passes through a non-Retina resolution intermediate stage, and after that it is of course worthless to upscale it again.
Comment 91 Emmeran Seehuber 2020-12-02 12:43:34 UTC
(In reply to Tor Lillqvist from comment #88)
> Created attachment 167757 [details]
> Zoomed in screenshot of LO with the above patch
> 
> As can be seen, the letters are quite grey, you don't see many fully black
> pixels at all.

Are you really sure that this has nothing to do with the CALayer? For me it seems this is still blurry because it has been upscaled. Just the more gray antialised font shading makes this less obvious.

I found this regarding CALayer and blurryness:

https://stackoverflow.com/questions/25746368/ios-drawing-in-calayers-drawincontext-is-either-pixelated-or-blurry-on-retina

It's for iOS, but maybe it applies for macOS too? At least it seems to be the same problem. No idea if the proposed fix there can be applied on macOS
Comment 92 Tor Lillqvist 2020-12-02 12:48:06 UTC
No, I am *sure* this has something to do with Core Animation Layers, as I said in comment #82. That is what changed in 10.14 and 11.0, after all. But most likely the code in LO "works against the system" in some way.