In Latin poetry, it is necessary to indicate the length of the vowels. These can be short (marked with a breve as "ă"), long (marked with a macron as "ā") or common (marked with a breve upon the macron as "ā̆"). As mentioned in the answer by ajlittoz in https://ask.libreoffice.org/en/question/284076/hide-dotted-circle-when-using-a-combining-character/, the common vowels are not available in the Unicode base-set, but can be obtained with combining diacritics (namely the "Combining Breve" or U0306) : the above example "ā̆" is a "a-macron" (U0101) followed by a "Combining breve" (U0306).
Things that are easy to render in Firefox or TextEdit (the basic editor on Mac) desappear in LO Writter and are poorly rendered in Calc (see attached, if I find where). The example of "Āttī̆lă" is even more surprizing in Writter.
Similar problem in https://bugs.documentfoundation.org/show_bug.cgi?id=139210
It may be related to the same problem observed in Qt, long ago. The break was related to the update from Qt 5.2 to 5.3
Steps to Reproduce:
1.Copy the simple example of two words :
and paste it either in Writter or Calc.
The present result is wrong in Writter (the breve on top of the macron does not appear in patres, and the combining breve leads to the duplication of the i-macron in Attila).
In Calc, the combining breve caracters appear, but they are displaced to the right (instead of being centered).
Already present in release 18.104.22.168
It had worked properly a long time ago (I do not remember the version number, 4 probably)
The combining breve should sit on top of the macron, centered with the main character.
User Profile Reset: No
Created attachment 168660 [details]
Same text in Writer and TextEdit
Created attachment 168661 [details]
Previous text in Calc
I forgot to mention that the combining breve is present in Writter, even though it is not visible. If one selects and copies, in LO Writter, the word "patres" or "Attila" (with its two i-macron), and pastes it again in TextEdit the common vowels re-appear !
Created attachment 168679 [details]
combining diacritics are font dependent, here on Win build
Confirmed on Windows and actually a know issue with Liberation fonts (Serif or Sans). But it is font dependent.
So, any better on macOS if you try it with a font with correct metrics?
Libertinus (Serif or Mono)--Libertinus Sans is bad
Let us know if on macOS selecting a different font with correct metrics behaves.
Created attachment 168680 [details]
MacOS Times and Arial
It is fine (although not perfect for the a-common) with Times New Roman or Arial.
It might be OK, if the position of the combining breve is not exact. But it's puzzling that it can desappear or lead to a duplication of a character that is not there.
(In reply to PhVerkerk from comment #6)
> Created attachment 168680 [details]
> MacOS Times and Arial
> Yes !
> It is fine (although not perfect for the a-common) with Times New Roman or
> It might be OK, if the position of the combining breve is not exact. But
> it's puzzling that it can desappear or lead to a duplication of a character
> that is not there.
Would note that in your attached clip (attachment 168660 [details]) of Writer that the font is show as Calibri that is not present on the system (indicated by its entry in italics). Meaning that a font fallback had to occur to render the text span.
The issue is with the fallback replacement--but unclear if it is in macOS font handling or with LibreOffices harfbuzz support.
And, it is fair to say the combining diacritics function correctly when used with a font that correctly defines their metrics. Not sure anything else can be done with missing or badly designed fonts.
Created attachment 168682 [details]
Mac OS Noto and Liberation
Noto seems fine too.
Liberation Sans gives a good result for i-common, but not for a-common.
OK for the statement that some fonts are badly designed. BUT, once upon a time, it worked better. It seems unlikely that the fonts got worse during an update of Qt or of LO. It is more probable that the font renderer became less efficient in rendering badly designed fonts (maybe sticking better to some official preconisations). Is it an improvement ?
(In reply to PhVerkerk from comment #8)
> Created attachment 168682 [details]
> Mac OS Noto and Liberation
> Noto seems fine too.
> Liberation Sans gives a good result for i-common, but not for a-common.
> OK for the statement that some fonts are badly designed. BUT, once upon a
> time, it worked better. It seems unlikely that the fonts got worse during an
> update of Qt or of LO. It is more probable that the font renderer became
> less efficient in rendering badly designed fonts (maybe sticking better to
> some official preconisations). Is it an improvement ?
That likely happened at the LibreOffice 5.3 release (experimental at 5.2) when project implemented Harfbuzz and replaced most/all macOS CoreText for consistent font shaping and layout cross platform.
I suspect these all are font bugs. Please make sure to specify the exact same font when testing with other applications, and please also note that macOS system applications (eg. TextEdit) might try to position the diacritics themselves if the font does not provide positioning information. LibreOffice might do this as well, but under more strict conditions. It is advisable to chose fonts that properly support the characters you need.