Bug 138122 (blurry_text) - LibreOffice text blurry on Retina displays on macOS 11
Summary: LibreOffice text blurry on Retina displays on macOS 11
Status: RESOLVED FIXED
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: Thorsten Wagner
URL:
Whiteboard: target:7.2.0 target:7.1.1 target:7.1....
Keywords:
: 133837 138198 138202 138211 138216 138236 138381 138460 138565 138613 138709 138928 138941 139806 139945 139950 140237 140390 140423 140430 140761 140858 140864 141253 141308 141344 141431 (view as bug list)
Depends on:
Blocks: HiDPI
  Show dependency treegraph
 
Reported: 2020-11-11 06:29 UTC by Alexander Barris
Modified: 2021-04-05 19:34 UTC (History)
70 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
Blurry 6.4.7.2-Sharp 7.2.0.0Alpha0+ (378.71 KB, image/png)
2021-01-21 15:27 UTC, G
Details
Blurry 6.4.7.2-Sharp 7.2.0.0Alpha0+ (378.71 KB, image/png)
2021-01-21 15:29 UTC, G
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 (allotropia) 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 Comment hidden (no-value)
Comment 69 Tor Lillqvist 2020-11-27 17:07:45 UTC Comment hidden (no-value)
Comment 70 Mugs 2020-11-27 22:19:44 UTC Comment hidden (no-value)
Comment 71 Tor Lillqvist 2020-11-27 22:34:00 UTC Comment hidden (no-value)
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 (no-value)
Comment 81 Tor Lillqvist 2020-12-01 06:42:16 UTC Comment hidden (no-value)
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.
Comment 93 lupurus 2020-12-02 13:44:20 UTC
Go to vcl/quartz/salvd.cxx

In bool AquaSalVirtualDevice::SetSize( tools::Long nDX, tools::Long nDY ) add this:

float fScale = 1.0f;
if (pSalFrame->getNSWindow())
    fScale = [pSalFrame->getNSWindow() backingScaleFactor];

maBitmapContext.set(CGBitmapContextCreate(pRawData, nDX * fScale, nDY * fScale, 8, nBytesPerRow,
GetSalData()->mxRGBSpace, nFlags));


Now everything is crispy clear. Unfortunately LO became extremely slow with that. Maybe someone knows more?
Comment 94 Tor Lillqvist 2020-12-02 13:52:59 UTC
How can that work? Surely correspondingly more space must be allocated for the pRawData in that case, too? The docs for CGBitmapContextCreate say:

data
A pointer to the destination in memory where the drawing is to be rendered. The size of this memory block should be at least (bytesPerRow*height) bytes.

and the "height" parameter we pass with such a change is nDY * fScale, and bytesPerRow is (mnBitmapDepth * nDX) / 8, i.e. nDX * 4.
Comment 95 lupurus 2020-12-02 13:58:26 UTC
Take a look at salgdiutils.cxx in bool AquaSalGraphics::CheckContext(). I copied the code from there. It's a strange problem, because some of the text was blurred and some not. So there must be a difference between for example drawing the text in the Combobox and the text in the popup of the combobox.
Comment 96 Tor Lillqvist 2020-12-02 14:02:05 UTC
But in AquaSalGraphics::CheckContext(), the first parameter to CGBitmapContextCreate() is nullptr, it is the function itself that allocates the necessary amount of memory.
Comment 97 lupurus 2020-12-02 15:21:50 UTC
(In reply to Tor Lillqvist from comment #94)
> How can that work? Surely correspondingly more space must be allocated for
> the pRawData in that case, too? The docs for CGBitmapContextCreate say:
> 
> data
> A pointer to the destination in memory where the drawing is to be rendered.
> The size of this memory block should be at least (bytesPerRow*height) bytes.
> 
> and the "height" parameter we pass with such a change is nDY * fScale, and
> bytesPerRow is (mnBitmapDepth * nDX) / 8, i.e. nDX * 4.

The interesting thing is: I get an error in the console: 'CGBitmapContextCreate: invalid data bytes/row: should be at least ...'

If I then say 

const int nBytesPerRow = (mnBitmapDepth * nDX * fScale) / 8;

instead of

const int nBytesPerRow = (mnBitmapDepth * nDX) / 8;

the text gets blurred again.
Comment 98 Tor Lillqvist 2020-12-02 16:16:00 UTC
If you add this to your changed code after the call to CGBitmapContextCreate():

            SAL_DEBUG("maBitmapContext.get()=" << maBitmapContext.get());

you will see that the call actually fails. So is this much of the complexity in there actually unnecessary? Mind-boggling...
Comment 99 Tor Lillqvist 2020-12-02 23:11:27 UTC
The commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=959e8ae7ea33ce94dd80ee8ea172b6db64593873 btw says:

> A known issue is that VirtualDevice also needs to take scaling
> into account, which it currently doesn't, so the text is still
> blurry on a HiDPI screen, but that was already true previously
> and is something that will be done in a different change.

But apparently that was not done while the developer still remembered what was to be done.
Comment 100 Telesto 2020-12-03 07:27:30 UTC
Not sure if relevant at all, but this might influence they font quality
https://www.macrumors.com/how-to/disable-font-smoothing-in-macos-big-sur/
Comment 101 Mark Byrn 2020-12-03 13:59:17 UTC
(In reply to Telesto from comment #100)
> Not sure if relevant at all, but this might influence they font quality
> https://www.macrumors.com/how-to/disable-font-smoothing-in-macos-big-sur/

Tried that but didn't have any effect.
Comment 102 lupurus 2020-12-05 14:21:46 UTC
What could be a next point to investigate: Why is the text in the Combobox sharp, but the text in the dropdown not? And why is the text in the style sidebar sharp as well? Does anyone know what is the name of the sidebar component? Where can I find it in the code?
Comment 103 lupurus 2020-12-05 17:24:03 UTC
I came so far: 

1) The "normal" text in a Combobox is drawn in 

vcl/source/control/imp_listbox.cxx in

void ImplListBoxWindow::DrawEntry(vcl::RenderContext& rRenderContext, sal_Int32 nPos, bool bDrawImage, bool bDrawText)

in line 1728: rRenderContext.DrawText(aTextRect, aStr, nDrawStyle);

2) If you open the font combobox in the toolbar, this entry is using a different method, it uses a custom draw method in

vcl/source/control/imp_listbox.cxx

void ImplListBoxWindow::ImplPaint(vcl::RenderContext& rRenderContext, sal_Int32 nPos)

in line 1641: 
UserDrawEvent aUDEvt(this, &rRenderContext, aRect, nPos, bSelected);
maUserDrawHdl.Call( &aUDEvt );

3) The style entry in the styles sidebar is a treeview and gets drawn in

vcl/source/treelist/treelistbox.cxx

void SvTreeListBox::DrawCustomEntry(vcl::RenderContext& rRenderContext, const tools::Rectangle& rRect, const SvTreeListEntry& rEntry)

in line 2863: aCustomRenderHdl.Call(std::tuple<vcl::RenderContext&, const tools::Rectangle&, const SvTreeListEntry&>(rRenderContext, rRect, rEntry));

(I cannot find, what function is calling DrawCustomEntry)

----------------

So the big question is: Why is 3) sharp and 2) not? They seem to do the same. Maybe just the RenderContext is different?
Comment 104 Mark Simon 2020-12-07 04:00:24 UTC
Again, for what it’s worth, I am currently editing a document with tracking, and I see that the comments are clear. The ▾Comments heading above is blurry.

At a zoom of 125% the document isn’t too unreadable, though I would hate to make a career of using it this way.
Comment 105 Ming Hua 2020-12-07 10:07:40 UTC
*** Bug 138709 has been marked as a duplicate of this bug. ***
Comment 106 Uwe Auer 2020-12-15 10:36:37 UTC
*** Bug 138928 has been marked as a duplicate of this bug. ***
Comment 107 Aron Budea 2020-12-15 14:45:22 UTC
*** Bug 138941 has been marked as a duplicate of this bug. ***
Comment 108 war 2020-12-16 09:55:59 UTC Comment hidden (no-value)
Comment 109 Jean 2020-12-20 18:08:44 UTC Comment hidden (no-value)
Comment 110 Theo 2020-12-20 19:15:17 UTC Comment hidden (obsolete)
Comment 111 Theo 2020-12-20 19:15:32 UTC Comment hidden (no-value, obsolete)
Comment 112 antonusanov 2020-12-20 19:46:46 UTC Comment hidden (no-value)
Comment 113 Commit Notification 2020-12-30 13:10:27 UTC Comment hidden (no-value)
Comment 114 Thorsten Wagner 2020-12-30 13:50:02 UTC
After investigation and refactoring of AquaSalVirtualDevice::SetSize and AquaSalGraphics::SetVirDevGraphics I was not able to archive sufficient results with doubeling bufferspace and scale. But there is another observation I want to share:

Replacing

const int nFlags = kCGImageAlphaNoneSkipFirst

by

const int nFlags = kCGBitmapByteOrder32Host;

in AquaSalVirtualDevice::SetSize will result in problems with image alpha channel as expected. Furthermore performace is bad and application will become unresponsive from time to time.

But text and graphics are sharp now although bitmap buffer size has not been increased. Will take a look in this direction next.

@ Tor: The parameters for AquaSalGraphics::SetVirDevGraphics seem to allow calling with either a GCLayer on a CGBitmapContext or with a CGBitmapContext only (without a GCLayer on top). As AquaSalGraphics::SetVirDevGraphics is called from AquaSalVirtualDevice::SetSize only for now, both parameters are not required. But these parameters are not the reason of blurry text and graphics when set correctly.
Comment 115 Thorsten Wagner 2020-12-30 14:38:12 UTC
Just to be complete: All blurring (combo box dropdowns, Writer main window, Calc main window, etc.) is caused by double buffering from the main code using the VCL virtual device, in this case initialized by AquaSalVirtualDevice::SetSize and AquaSalGraphics::SetVirDevGraphics.
Comment 116 Tor Lillqvist 2020-12-30 17:52:19 UTC
Yes, I noticed the same about the first parameter to AquaSalGraphics::SetVirDevGraphics () earlier today, and added a comment about it;)

In general, it is not entirely clear to me what the benefit of wrapping a CGLayerRef in CGLayerHolder and a CGContextRef in CGContextHolder is. But I am probably missing something.
Comment 117 Arne 2021-01-03 04:55:41 UTC Comment hidden (no-value)
Comment 118 Tor Lillqvist 2021-01-06 10:38:34 UTC
Interesting observation: Running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice --writer

will make the text you type into the Writer window show up crisp and nice.

But running

> VCL_DOUBLEBUFFERING_ENABLE=1 instdir/LibreOfficeDev.app/Contents/MacOS/soffice /path/do/document.odt

does now change how it looks.

Very weird.

But note that even in the soffice --writer case, even if the text shows up crisp, there are other problems, like the selection indicators don't show up at all if you select part of the text you have entered. The VCL_DOUBLEBUFFERING_ENABLE environment variable is related to an abandoned effort to make VCL and the way LO uses it saner, or something. Here is a discussion we just had on IRC (edited for clarity):

> tml__:   What does your comment "FIXME: this must disappear as we move to
>          RenderContext only" in vcl/source/window/paint.cxx mean?
> 
> vmiklos: It means that if application code (outside vcl) would store no state
>          during rendering (on the outputdevice), then such copying would not
>          be necessary. but today i guess we learned that app code won't be
>          changed that way (too much work).
> 
> tml__:   Idly wonders what RenderContext is.
> 
> vmiklos: RenderContext is just a typedef to OutputDevice; the idea was to not
>          paint at random times, but rather only paint when vcl gives you a
>          RenderContext. That's how practically all toolkits work.
>          But Skia, gtk3, Qt (and I would guess macOS, but haven't checked)
>          all gave up on changing non-vcl code, rather they maintain this
>          backbuffer (so non-vcl code can draw at random times) and just
>          copy the backbuffer to the final place when they get a drawing
>          context from the OS/underlying toolkit (on idle).
> 
> tml__:   I didn't even know that there had been such an attempt/wish/plan to
>          "move to RenderContext only".
> 
> vmiklos: https://speakerdeck.com/kendy/rendercontext-and-double-buffering it
>          was an effort 6 years ago. I think the hope was that this way one
>          more backbuffer can be avoided for (back then) OpenGL, and the result
>          was that, no, too much work, just do this for OpenGL (and now Skia)
>          the same way as gtk3 does. Like, if this would work, then each
>          backend would not need their own backbuffer. (But it does not work.)
> 
> tml__:   And is this RenderContext effort then the same as that which
>          introduced that VCL_DOUBLEBUFFERING_ENABLE etc? Or unrelated?
> 
> vmiklos: Same
> 
> mmeeks:  AFAIR we had some death-march to try to make it work everywhere properly; that failed in the end,
>          and we did something -much- simpler that didn't burn several engineers for weeks =)
Comment 119 Thorsten Wagner 2021-01-10 20:29:54 UTC
Some first results: Text is sharp now within dropdown windows and within application windows (Writer, Calc, etc.) on retina displays too.

I am currently preparing a first revision of patch for testing (not for committing). Patch will include the following:

(1) Removal of path to handle application as being linked again 10.13 SDK

(2) salvd.cxx: Refactoring/rework of AquaSalVirtualDevice::SetSize to use quad storage size for retina displays

(3) salgdicommon.cxx: Refactoring/rework of AquaSalGraphics::SetVirDevGraphics to apply double scaling to virtual devices too

(4) salgdicommon.cxx: Refactoring/rework of AquaSalGraphics::copyBits and AquaSalGraphics::copyArea to use a new unified method AquaSalGraphics:copyScaledArea to handle sources from scaled virtual devices as well

(5) salbmp.cxx: Workaround for QuartzSalBitmap to downsample bitmaps from scaled layers (this workaround has still to be replaced by an implementation of scaled bitmaps)

(6) Environment variable VCL_FORCE_WINDOW_SCALING to activate window scaling on non retina displays too (should look the same as without window scaling, but very useful for testing on a non retina display)

Bitmap workaround causes blurry bitmap representations on retina displays as on non retina displays as well. This is desired for now, because implementation of scaling-aware bitmaps has still to be done. On retina displays it looks similar as on Mojave or Catalina.

After patch has been tested especially according to unwanted side effects, following steps have to be done:

(1) QuartzSalBitmap has to be extened to handle bitmaps from scaled sources, workaround has to be removed afterwards

(2) Environment variable VCL_FORCE_WINDOW_SCALING has to be removed and replaced by a scaling of 2.0f on macOS (and by a scaling from the main display on IOS). After application, windows are able to be moved between retina and non retina displays without showing blurry text again.

I will post a link to the patch here as soon as it is ready for testing.
Comment 120 Thorsten Wagner 2021-01-10 23:07:51 UTC
Patch submitted to Gerrit:

https://gerrit.libreoffice.org/c/core/+/109072

Further observations:

(1) As SDK 10.13 is no longer preset, dark mode will be enabled for LO if it is enabled globally. Dark mode is currently not implemented in a usable manner for macOS. As a consequence dark mode needs to be disabled as default now, maybe controlled by an environment variable for futher development.

(2) When presenting Impress presentations LO hangs after stepping through some slides. I do not know whether this is caused by this patch for now. In debug mode FPS display is not cleared for refresh too.
Comment 121 Tor Lillqvist 2021-01-11 09:18:52 UTC
I can reproduce the hang in a freshly built LibreOffice even without your patch. I will file a bug (and try to fix).
Comment 122 Tor Lillqvist 2021-01-11 10:23:21 UTC
Filed bug #139535 for the hang (which is caused by an assertion failure, which the code then tries to handle, but fails).
Comment 123 lupurus 2021-01-11 10:30:42 UTC
(In reply to Thorsten Wagner from comment #120)
> Patch submitted to Gerrit:
> 
> https://gerrit.libreoffice.org/c/core/+/109072
> 
> Further observations:
> 
> (1) As SDK 10.13 is no longer preset, dark mode will be enabled for LO if it
> is enabled globally. Dark mode is currently not implemented in a usable
> manner for macOS. As a consequence dark mode needs to be disabled as default
> now, maybe controlled by an environment variable for futher development.
> 
> (2) When presenting Impress presentations LO hangs after stepping through
> some slides. I do not know whether this is caused by this patch for now. In
> debug mode FPS display is not cleared for refresh too.

Thank you very much, it seems to work!!! Just resizing the window looks funny, because the items in the toolbar are getting stretched during resizing. But that's okay for the moment.

For me, the dark mode is not activated, I don't know why. But if you experience it: For now you can opt out from the dark mode with NSRequiresAquaSystemAppearance set to true in the info.plist. More informations here: https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app#2993818
Comment 124 Tor Lillqvist 2021-01-11 10:33:53 UTC
Suggested fix for the assertion failure that causes the hang mentioned above in https://gerrit.libreoffice.org/c/core/+/109083  .

Note to people following this bug: That assertion failure and hang is not as such related to this bug, I just mention it here as the hang was mentioned in an earlier comment.
Comment 125 Frank Fuchs 2021-01-11 10:40:17 UTC
I know this discussion should really be focused on getting the bug fixed.
But I wanted to say that I am impressed by Thorsten's willingness to dig into it and by his work on getting it fixed the "hard way" and not through another strange workaround.
Thanks!
Comment 126 Thorsten Wagner 2021-01-11 21:51:13 UTC
Thank you all for your comments and help! I would like to ask you for your opinion concerning the next steps. From my point of view there are two possibilities:

(1) Resolve all the remaining issues (main work is to extend QuartzSalBitmap to handle scaled bitmaps and not to downsample them); commit patch to master as soon as it is complete

(2) Finalize patch with the current scope of work; commit patch early and deliver a second patch for the rest as soon as it is ready

For case 2, VCL_FORCE_WINDOW_SCALING control would be kept in place. Behaviour would be as follows:

(1) Bitmaps still remain blurry on retina displays (but it seems to be acceptable on laptop displays for now; on larger displays as on 5K iMacs or Mac Pros it will be visible)

(2) Moving windows between non retina displays and retina displays will cause blurry text again as long a non retina display is the primary display - this is the same as now on Mojave and Catalina without patch (and will be resolved by removing the VCL_FORCE_WINDOW_SCALING control and setting scaling to 2.0f as default on macOS)
Comment 127 Frank Fuchs 2021-01-11 21:59:48 UTC
I am in favor of no. (1) for two reasons:
* While you're at it, it's great for the community that you strive to really solve all the problems. Splitting it up always runs the risk that step 2 never gets done because other tasks surface :-)
* There is enough time until cut-off for 7.2. Backporting to 7.1 (if feasible) afterwards is a "nice-to-have" option
Comment 128 Alexander Barris 2021-01-12 01:03:29 UTC
(In reply to Thorsten Wagner from comment #126)
> Thank you all for your comments and help! I would like to ask you for your
> opinion concerning the next steps. From my point of view there are two
> possibilities:
> 
> (1) Resolve all the remaining issues (main work is to extend QuartzSalBitmap
> to handle scaled bitmaps and not to downsample them); commit patch to master
> as soon as it is complete
> 
> (2) Finalize patch with the current scope of work; commit patch early and
> deliver a second patch for the rest as soon as it is ready
> 
> For case 2, VCL_FORCE_WINDOW_SCALING control would be kept in place.
> Behaviour would be as follows:
> 
> (1) Bitmaps still remain blurry on retina displays (but it seems to be
> acceptable on laptop displays for now; on larger displays as on 5K iMacs or
> Mac Pros it will be visible)
> 
> (2) Moving windows between non retina displays and retina displays will
> cause blurry text again as long a non retina display is the primary display
> - this is the same as now on Mojave and Catalina without patch (and will be
> resolved by removing the VCL_FORCE_WINDOW_SCALING control and setting
> scaling to 2.0f as default on macOS)

I feel like, as a user, I would want the whole bug fixed correctly and completely, not something that is thrown together and hoped to be worked on at a future date. So I'm in favor of 1. As much as 2 can work, we're still on RC1 for 7.1, and because this is targeted for 7.2, it means that it doesn't need to be hastily thrown in.
Comment 129 Tor Lillqvist 2021-01-12 07:35:32 UTC
Alexander, nobody has said that this is "targeted for 7.2 [only]". Back-porting to 7.1 is not hard and I don't see why that would not be done. (That is what is done with important bug fixes, they are almost always back-ported to the stable branch from master.)

Even back-ports to 7.0 (for LibreOffice Vanilla in the App Store) and cp-6.4 (for Collabora Office in the App Store) will certainly be considered.
Comment 130 Ming Hua 2021-01-12 08:45:41 UTC
(In reply to Tor Lillqvist from comment #129)
> Alexander, nobody has said that this is "targeted for 7.2 [only]".
I think Alexander was misunderstanding what "target:7.2.0" in the Whiteboard field means.

That tag was added automatically with the commit in comment 113.  I've now removed it.
Comment 131 Tor Lillqvist 2021-01-12 08:50:14 UTC
I am in favour of option 2. (Finalising the current patch should include dropping the gratuitous whitespace changes from it. But I am sure Thorsten knows that.)
Comment 132 Mike Kaganski 2021-01-12 08:52:24 UTC
(In reply to Tor Lillqvist from comment #131)
> I am in favour of option 2.

Totally agree. Additionally, creating too large patches will make it more difficult to see the actual reason of possible regressions; patches should be as small as possible for a certain limited functional change.
Comment 133 Thorsten Wagner 2021-01-12 09:54:53 UTC
Ok, keeping this all in mind I will proceed this way:

(1) Finalize patch with current scope of work (hopefully during next weekend): Thorsten

(2) Code review and commit to master: Tor

(3) Port to cp branches (maybe): Tor

(4) Extend QuartzSalBitmap (earliest in two weeks) and prepare a second patch: Thorsten

(5) Code review and commit to master when it is ready

(6) Cherry pick for release branch and backport when all is ready

@ Tor: Hope this is ok for you!

Remaining discussion concerning the current patch will take place on the code review pages.
Comment 134 Commit Notification 2021-01-17 18:21:46 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a167625314bf36b735176ed488e6ba9b5e9b675

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 135 Thorsten Wagner 2021-01-17 20:15:42 UTC
Additional information concerning performance:

I had the opportunity to test on a large rentina display (iMac Pro and Mac Pro) with macOS Catalina. Results are as follows:

LO 7.0.3: Sharp text (as expected), very bad performance, scrolling with two pages side by side in Writer unusable due to bad performance

LO 7.2.0 with patch: Sharp text (as expected), much better performance, fast scrolling with two pages side by side in Writer

Currenty CGLayer is used for layered graphics. A CGLayer is as far as I know only stored in main memory (no GPU memory). Performace impact seems to be caused by scaling within main memory (probably done by applications linked against SDK 10.13 implicitly). As memory is quad of original memory now some scaling is no longer required and performance has been increased significantly.

There are further significant optimizations possible by replacing CGLayer by CALayer (to use GPU memory) - but this is not in the scope of this change.

For the ongoing next step of extending QuartzSalBitmap I will continue to use CGLayer to keep the implementation consistent.

@ Tor: Thank you very much for merging the first patch!
Comment 136 Commit Notification 2021-01-17 20:41:55 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e7ace1d043cc8bdf6c03097932a00cbbdc3cf557

tdf#138122: Fix vcl for iOS after 1a167625314bf36b735176ed488e6ba9b5e9b675

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 137 Arne 2021-01-18 05:32:23 UTC
Installed Daily build "2021-01-18 05:05:06" on MacBookPro11,4 (15" Retina, mid 2015) with MacOS 11.1. All text is now clear. Performance seems normal. Looks like a successful patch so far.
Comment 138 Andrew 2021-01-18 06:00:37 UTC
Just installed Jan 18 Daily Build on hackintosh Big Sur 11.2 beta.  Text nice and clear in Calc and Writer.
Comment 139 Andrew 2021-01-18 06:02:42 UTC
Monitor LG 4K @ 1,920x1,080
Comment 140 Commit Notification 2021-01-18 07:29:07 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/44dfa5ef2ffac1740ba270978de3e1b12484b5e8

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.1.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 141 Commit Notification 2021-01-18 07:31:28 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/2fc4d9acb2e04a2cb868a82a394bf23239487511

tdf#138122: Fix vcl for iOS after 1a167625314bf36b735176ed488e6ba9b5e9b675

It will be available in 7.1.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 142 Timur 2021-01-21 09:58:53 UTC
*** Bug 133837 has been marked as a duplicate of this bug. ***
Comment 143 Xisco Faulí 2021-01-21 10:01:46 UTC
*** Bug 139806 has been marked as a duplicate of this bug. ***
Comment 144 Timur 2021-01-21 10:10:37 UTC
For folks in CC: this bug had a fix. It would be useful that you test it with daily master from https://dev-builds.libreoffice.org/daily/master/current.html and write you result here, adding your original bug.
Comment 145 Ion Jaureguialzo Sarasola 2021-01-21 10:39:39 UTC
I've just installed daily libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-01-21_10.38.59 with Spanish language pack on macOS 11.1 (20C69) and everything looks clear again on every connected monitor (external 4K screen and macBook's internal retina display).

In Writer, the text on the main editor is crisp and other interface elements such as the font selector or the are not blurry anymore.

In Calc, the text is now clear again when leaving cell edit mode.
Comment 146 Roman Kuznetsov 2021-01-21 14:49:40 UTC
(In reply to Commit Notification from comment #140)
> Thorsten Wagner committed a patch related to this issue.
> It has been pushed to "libreoffice-7-1":
> 
> https://git.libreoffice.org/core/commit/
> 44dfa5ef2ffac1740ba270978de3e1b12484b5e8
> 
> tdf#138122 Add window scaling for retina displays on macOS
> 
> It will be available in 7.1.1.
> 

Thorsten, will you plan backport it to 7.0?
Comment 147 mmacleod 2021-01-21 14:59:00 UTC
Daily master solves the blurriness issue in Calc for me on Big Sur 11.1.
Comment 148 G 2021-01-21 15:26:28 UTC
Fonts on the 7.2.0.0Alpha0+ is looking Great
Fonts are Sharp, just the Huge Icons and and Space that everithing uses is huge, I understand the Touch approach, but soon we will need more resolution just to fit the About Libreoffice window.
Comment 149 G 2021-01-21 15:27:49 UTC Comment hidden (no-value)
Comment 150 G 2021-01-21 15:29:11 UTC Comment hidden (no-value)
Comment 151 Thorsten Wagner 2021-01-21 19:41:12 UTC
(In reply to Roman Kuznetsov from comment #146)
> (In reply to Commit Notification from comment #140)
> > Thorsten Wagner committed a patch related to this issue.
> > It has been pushed to "libreoffice-7-1":
> > 
> > https://git.libreoffice.org/core/commit/
> > 44dfa5ef2ffac1740ba270978de3e1b12484b5e8
> > 
> > tdf#138122 Add window scaling for retina displays on macOS
> > 
> > It will be available in 7.1.1.
> > 
> 
> Thorsten, will you plan backport it to 7.0?

Next QuartzSalBitmap has to be modified to avoid blurry graphics too (see comment 133). Backporting is ok, but I suggest to do that when all is ready (including graphics).
Comment 152 Mark Simon 2021-01-21 22:53:41 UTC
(In reply to Timur from comment #144)
> For folks in CC: this bug had a fix. It would be useful that you test it
> with daily master from
> https://dev-builds.libreoffice.org/daily/master/current.html and write you
> result here, adding your original bug.

Text looks perfect on my system: Retina iMac with two non-retina additional screens. I can drag the window anywhere and it looks clear everywhere.

I did note that the status bar at the bottom doesn’t take kindly to moving from one window to another. If the document was opened on the Retina screen, dragging the window to a non-retina screen causes the status bar text to render half the size, and the remain space filled with black. If the document was opened on the non-retina screen and dragged to the Retina screen, the status bar text doubles in size.

I also notice some weirdness in zoom. A document opened on the non-retina screen starts off at 125%, which is fine. However, the actual text is monstrously large. If I zoom down to 100%, it’s still large, and there’s some white space when I click left margin.

When I open up the Customize dialog on the non-retina screen, the drop-down menus are also double size.

All of this suggests that the font size is not handling the mix of retina and non-retina screens.

Would it be OK to attach a video of this behaviour?

I don’t know whether it’s my imagination, but the text appears to be drawing faster too. In the past, when I type something, there seems to be s slight lag in rendering the text.

I have only tried Writer. I also note that the Alpha version I tried has no awareness of my settings and history, so it’s not practical to test it further on a real project. I has also just crashed.
Comment 153 Thorsten Wagner 2021-01-21 23:37:57 UTC
Moving windows between screens of different scale is currently not implemented. This is work in progress within the scope of this issue - the current patch is only the first patch. A video is not required (at least for me).

Drawing text should be faster as prior to patch. Drawing graphics is work in progress too and is currently not faster as prior to patch.
Comment 154 Timur 2021-01-22 09:57:34 UTC
Note for moving that there are See Also bug 85499 and (a duplicate?) bug 108801.
Comment 155 Commit Notification 2021-01-25 11:55:39 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1-0":

https://git.libreoffice.org/core/commit/a5cd681dce3f7f941ae00cfc4aab2718941d8fcd

tdf#138122 Add window scaling for retina displays on macOS

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 156 Thorsten Wagner 2021-01-27 00:45:05 UTC
Patch has been merged to LO 7.1.0 which is RC 2 now. This was not planned (see comment 133). However multiple display configurations should be supported to use patch in a release. Thus I prepared a second patch:

(1) Display scaling is activated if a single retina display is present at least (independent whether this is the main display or not). Moving windows between displays is now possible in all multi-display configurations. Issue reported in comment 152 should be fixed.

(2) As implementation of window scaling for bitmaps is still ongoing and will take some time (not trivial) window scaling is not activated generally. This is planned for the complete implementation prime. Selective activation of display scaling is required to avoid performance degradation on non-retina-only configurations. This degradation would not significant but present due to upscaling and downscaling of bitmaps.

(3) Adding displays while LO is running is not supported by this patch. Adding a retina display to non-retina-only configurations causes no change in display scaling. Quitting and restaring LO is required in this case (should be acceptable for now).

Please find the second patch here:

https://gerrit.libreoffice.org/c/core/+/110002

It would be very nice to get it reviewed, tested, and merged to LO 7.1.0 before LO 7.1.0 will be published. This will help to avoid tickets.
Comment 157 Timur 2021-01-27 07:53:49 UTC
Hwllo Thorsten. Thanks for your work on this long-standing bug. 
I'm not in MacoS so please clarify: is latest patch related to bugs from See Also and Comnent 154?
If so, you may well close this one as Fixed and confines there, or close the other one referencing the commit. Thanks.
Comment 158 Commit Notification 2021-01-27 09:11:07 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f318b856ed055f1952276355f811153f6b29c93e

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 159 Tor Lillqvist 2021-01-27 09:38:13 UTC
Thorsten, you write "This was not planned", but even the first patch did fix things significantly for a significant number of of users, and did not introduce any new problems, right? So why not get it out there?
Comment 160 Thorsten Wagner 2021-01-27 09:47:59 UTC
(In reply to Tor Lillqvist from comment #159)
> Thorsten, you write "This was not planned", but even the first patch did fix
> things significantly for a significant number of of users, and did not
> introduce any new problems, right? So why not get it out there?

It is ok to get it out now, but handling of multiple displays was not prepared for end users (control by environment variable). This has been dropped with the second patch to make it ready for end users.
Comment 161 Thorsten Wagner 2021-01-27 09:51:56 UTC
(In reply to Timur from comment #154)
> Note for moving that there are See Also bug 85499 and (a duplicate?) bug
> 108801.

Yes, these two issues should be fixed by second patch.
Comment 162 Uwe Auer 2021-01-27 14:03:44 UTC
*** Bug 139945 has been marked as a duplicate of this bug. ***
Comment 163 Xisco Faulí 2021-01-28 09:42:35 UTC
*** Bug 139950 has been marked as a duplicate of this bug. ***
Comment 164 Commit Notification 2021-01-28 09:43:44 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b3737c638671ab39c5e6aaeaf5426d102392cc0a

Revert "tdf#138122 Detect window scaling for multi display configurations on macOS"

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 165 xyloforce 2021-02-02 14:08:37 UTC
I tested the latest dev version (build 7.1.1.0) and tested with Draw, Impress and Writer, and accross all these apps fonts are perfect. Many thanks for the fix !
Comment 166 Frank Fuchs 2021-02-10 17:36:36 UTC Comment hidden (obsolete)
Comment 167 Thorsten Wagner 2021-02-10 17:41:55 UTC
(In reply to Frank Fuchs from comment #166)
> Thorsten and Stephan:
> 
> I noticed that Thorsten's patch for "Detect window scaling for multi display
> configurations on macOS" was reverted by Stephan.
> Is there a new patch in the works?

As soon as I get Stephan's broken unit tests reproduced. I am working on this but on my build chain there are many unit tests broken not only those mentioned by Stefan and not only those which are possibly related to this issue - maybe an issue with my build environment but not identified until now.
Comment 168 Xisco Faulí 2021-02-15 18:24:07 UTC
*** Bug 140430 has been marked as a duplicate of this bug. ***
Comment 169 Commit Notification 2021-02-23 07:22:42 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0c36f364b14aacd0eeb53087ae2fce54402dc741

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 170 Yves Bertran Alvarez 2021-02-25 16:48:52 UTC
Hi, 
I tested today daily build 7.1.2.0.0+ on MAC OSX 10.16, and the text appears sharp and clean on Writer and Calc. The problem seems to be solved. 
thumbs up!
Comment 171 Thorsten Wagner 2021-02-25 20:28:00 UTC
(In reply to Yves Bertran Alvarez from comment #170)
> Hi, 
> I tested today daily build 7.1.2.0.0+ on MAC OSX 10.16, and the text appears
> sharp and clean on Writer and Calc. The problem seems to be solved. 
> thumbs up!

No, issue is not resolved completely. Text is working, Performance is ok, but bitmaps are a litte bit blurry. The latter is caused by a workaround currently in place. Bitmaps are work in progress. Issue will be resolved when scalable bitmaps have been implemented too.
Comment 172 war 2021-02-26 07:16:20 UTC
Fonts are clear, images are blurry
Comment 173 steve 2021-03-03 09:02:07 UTC
*** Bug 140761 has been marked as a duplicate of this bug. ***
Comment 174 Commit Notification 2021-03-05 13:22:56 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f8891b7f87957cc3f66805adf9b1e35a2189946b

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 175 Thorsten Wagner 2021-03-07 11:44:45 UTC
Backport of multi display support for LO 7.1 submitted to Gerrit:

https://gerrit.libreoffice.org/c/core/+/112106
Comment 176 Commit Notification 2021-03-08 08:23:41 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/6b3558e3c563427f1bdff7193151c57c59041ddb

tdf#138122 Detect window scaling for multi display configurations on macOS

It will be available in 7.1.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 177 Roman Kuznetsov 2021-03-08 21:42:11 UTC
*** Bug 140864 has been marked as a duplicate of this bug. ***
Comment 178 Timur 2021-03-11 13:21:21 UTC
*** Bug 140858 has been marked as a duplicate of this bug. ***
Comment 179 Roman Kuznetsov 2021-03-13 17:31:23 UTC
I got a feedback from my friend about macOS blur fonts/images on Retina display after Thorsten's patches - it looks fine and he tried with two displays , one is Retina and second isn't. He moved LO's window from one to second and back. It looks nice too.
Comment 180 French Frog 2021-03-14 19:36:56 UTC
It works. I just tested it on my retina with Big Sure, and it works perfectly. As said Roman, I transfered the window from one not retina screen to the retina, and it goes smoothly. I was a little bit sad until this evening, and know I enjoy my LO on retina.
Well done ! Nice job ! Thank you !
Comment 181 Yves Bertran Alvarez 2021-03-16 07:01:27 UTC
I tried yesterday LibreofficeDev v7.1.3 and it works fine on a retina mac. Thanks for solving the issue!
Comment 182 Thorsten Wagner 2021-03-16 12:29:03 UTC
Text issues are fixed for retina displays and for mixed display configurations. All fixes will be released with LO 7.1.2.

There are issues with bitmaps but these issues do not seem to be related to the changes in the scope of this issue and will be investigated here:

https://bugs.documentfoundation.org/show_bug.cgi?id=141063

Furthermore bitmaps are not displayed using retina quality. This is not as severe as it looked like with LO 7.1.1 because something other has changed in the meantime (see tdf#141063 too).

I am closing this record now because further development of retina quality bitmap rendering will take place here (this includes the reenablement of some on macOS currently disabled unit tests in the future):

https://bugs.documentfoundation.org/show_bug.cgi?id=141065

Thank you all for the discussions and for testing.
Comment 183 Roman Kuznetsov 2021-03-29 04:06:42 UTC
*** Bug 141253 has been marked as a duplicate of this bug. ***
Comment 184 Mike Kaganski 2021-03-29 06:49:31 UTC
*** Bug 141308 has been marked as a duplicate of this bug. ***
Comment 185 Roman Kuznetsov 2021-03-30 22:03:19 UTC
*** Bug 141344 has been marked as a duplicate of this bug. ***
Comment 186 steve 2021-04-03 10:58:29 UTC
*** Bug 141431 has been marked as a duplicate of this bug. ***
Comment 187 Roman Kuznetsov 2021-04-04 15:28:07 UTC
*** Bug 140237 has been marked as a duplicate of this bug. ***
Comment 188 Aron Budea 2021-04-04 15:30:36 UTC
*** Bug 140423 has been marked as a duplicate of this bug. ***
Comment 189 Aron Budea 2021-04-04 15:30:46 UTC
*** Bug 140390 has been marked as a duplicate of this bug. ***
Comment 190 Mike Kaganski 2021-04-05 10:58:22 UTC
*** Bug 141494 has been marked as a duplicate of this bug. ***