New font engine of LO 5.3 destroys on OSX 10.11 font design of all old and newly created documents.
Main problems: Letters of words merge into another AND letter space in between words gets huge gaps like blanks - terrible to look at, terrible to work with, terrible to read. ALSO: Initials don't work anymore.
I went back to LO 5.2.4, might upgrade to 5.2.5, but with 5.3 it's not possible to work all day long. It's a pain to look at the broken letter display. Very sad.
Please make this "cross-platform type uniformity" optional - I don't need it, I need readable documents, not some terrible 1990's or ancient Windows font rendering. This is a major downgrade! Thank you.
Steps to Reproduce:
Create Writer document, write or paste some text, look at it.
For broken Initials: Create a paragraph of text and chose to make an initial letter: it appears a blank space.
Broken font rendering.
Font rendering like on LO 5.2.4 and older.
User Profile Reset: No
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0
Created attachment 131092 [details]
my Writer test document
Created attachment 131093 [details]
text display on LO 5.3
Created attachment 131094 [details]
text display on LO 5.2.4
Not reproducible for me with LO 188.8.131.52.0+ built at home under Ubuntu 16.04 x86-64:
Build ID: a60a6f514c59e4a7e7fee239823d2e932c499bf6
Threads CPU : 4; Version de l'OS :Linux 4.4; UI Render : par défaut; VCL : gtk3; Moteur de mise en page : nouveau;
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Not reproducible with
Build ID: 1:5.3.0~rc3-0ubuntu1~xenial1.1
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; VCL: gtk3; Layout Engine: new;
Locale: fr-FR (fr_FR.UTF-8); Calc: single
In both cases drop caps are visible. There is the bug 101664 with drop caps in 5.3.0 and 5.2.0 that is fixed in next versions 5.2.6 and 5.3.1.
Best regards. JBF
I dug out Bug 89879 "Unify text layout to use HarfBuzz on all platforms". There it is written:
"HarfBuzz is a free software text layout engine, it is actively developed and supported, both Firefox and Chrome switched to using it on all platforms to avoid the situations outlined above, and I think LibreOffice should do the same."
OK, no problem with that. But in Chrome and Firefox for MacOS text rendering is (with HarfBuzz) excellent. So why is text rendering in LO 5.3 with HarfBuzz on MacOS not as good as on Firefox and Chrome? ("not as good" is an euphemism for terrible. See screenshots.)
screenshot of what I see in LO master attached, which looks a lot better than what screenshot for 5.3 from OP shows.
Can also not confirm using 5.3.
@DeepFlight5: Please try two things: Open LO > Preferences > View and check you are using identical settings as shown in my second screenshot.
Created attachment 131131 [details]
test display on LO 5.4 master 2017-02-09
Created attachment 131132 [details]
DeepFlight5, can you please copy paste the version info from Libreoffice > About (menubar).
Version: 184.108.40.206 Build-ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU-Threads: 2; BS-Version: Mac OS X 10.11.6; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de.UTF-8); Calc: group
Your LO 5.4 still looks bad (letters merging into another). Until LO 5.2.4 all was perfect.
I made a test screenshot of a LO 5.3 text and a PDF produced from this text by LO 5.3. It seems only a display problem in LO 5.3, the PDF export of LO 5.3 is perfect.
"View Settings" is as yours. I only have chosen "Small Toolbar Icons".
Created attachment 131133 [details]
Writer bad, PDF export good
*** This bug has been marked as a duplicate of bug 103322 ***
DeepFlight5: Please create a separate report for the initials problem.
Created attachment 177619 [details]
Looking at dancing glyphs in Justified mode
Created attachment 177628 [details]
There is also dancing glyphs with a Alignment Centered and changing font attribute for part of a Word
Created attachment 181789 [details]
1. Highlighting D of controlled, moves, the 'i' in air. After underlining air, the 'i' of in will also move (with air)
2. When highlighting the D of controlled, 'piston' moves.
Screencast taken with 160% zoom (but found this more often). 1920x1080
The problem occurs with 'Justified' alignment. It surely improved compared to my previous screencast, but not perfect
probably multiple runs, once the attributes of a part change its a new run of text and is laid out as a separate "thing" to text before and after it.
Putting aside the movement triggered by changing attributes of a piece of text I wonder if the original text rendering problem is solved by 7.4 or remains. (The broken initials was so glaring I assume that is not an issue anymore)
(In reply to Caolán McNamara from comment #19)
> probably multiple runs, once the attributes of a part change its a new run
> of text and is laid out as a separate "thing" to text before and after it.
I lack knowledge about text runs. What I find curious: introducing direct formatting, to some selection (word/glyph) [is this called a span?]. can - depending the location - cause a re-alignment of justified/ moving glyphs.
So applying an attribute, say highlighting to a selection (word/glyph), can cause a shift. Changing the attribute highlighting doesn't make any difference. Nor does adding some other attribute to the same selection. Removing the DF on the other hand causes a shift
It appears to happen independent of zoom-level, but easier to see with when zooming in.
Hebrew is even more prone to this
And well this brings this to mind:
https://git.libreoffice.org/core/+/6db39dbd7378351f6476f6db25eb7110c9cfb291%5E! although this is being beyond my understanding too. So this might be something totally different.
(In reply to Caolán McNamara from comment #20)
> Putting aside the movement triggered by changing attributes of a piece of
> text I wonder if the original text rendering problem is solved by 7.4 or
> remains. (The broken initials was so glaring I assume that is not an issue
Yes, there are no issues anymore, aside from the above