Below is a Windows-only issue of the new layout engine originally mentioned in  (using an 5.3 daily build).
Open attachment 128978 [details] (from bug 101599) in Writer.
Note how it looks like the bottom of screenshot attachment 128979 [details].
(the top screenshot is a different issue reported in bug 101599, and not relevant here)
As Khaled identified in :
"The second line is:
Everything is fine, until I combin \u20dd\u0364.
U+20DD is a combining circle, and U+0364 is a combining superscript e. So seeing a circle there is expect, but it looks misplaced in your screenshot."
Confirming based on comments in bug 101599.
I'm not sure if this is to be categorized as a HarfBuzz-regression, Khaled, please adjust as you see fit.
Please note that Liberation Serif does not have a U+20DD COMBINING ENCLOSING CIRCLE glyph -- so font fallback must occur, and that seems where the problem lies.
If you assign a font that provides coverage of both the combining glyphs you get very different results!
Retest with code2000 or symbola for example.
@Khaled, interesting in that that the monospace code2000 does about the best positioning each glyph in composing the combined character. So in addition to the return of fall-back losing its placement--the actual composition into the combining character may not be using font metrics, combined glyphs don't assemble as expected.
Created attachment 129077 [details]
combining glyph behavior is font dependent
(In reply to V Stuart Foote from comment #2)
Attached screen clip showing an issue
A couple of examples to show metrics for combining glyphs... in Code2000 and in Symbola (George Douros' Ancient Scripts)
Cursor to end of line, and Alt-X convert each:
Also, attachment 129077 [details] clip was with OpenGL enabled with HarfBuzz. With default GDI based rendering the Code2000 (design credit to James Kass) and Symbola render the same.
With the Arial and Segoe default rendering with GDI the "double struck" letters and other element positioning shifts a bit between the OpenGL and the GDI rendering. The rendering engine is doing different things when fall-back is involved.
Seeing a small shift in the position of combining marks when they are coming from different fonts is rather expected, since correct positioning require the glyphs to come from the same font. Even when they come from the same font, the positioning can be bad since not all fonts handle every combining mark correctly.
What is shown in attachment 128979 [details] is not expected though, the mark is shifted all the way to the beginning of the line which should not happen. Can someone else confirm this, and mat be added a screenshot here with a bigger zoom?
Created attachment 129093 [details]
LODev 5.4.0 20161128 w/OpenGL rendering
Created attachment 129095 [details]
LODev 5.4.0 20161128 w/Default GDI rendering
@Khaled, greater zoom as requested--on current 5.4.0 20161128 TB42 master--here with Default GDI rendering, and with OpenGL rendering in attachment 129093 [details]
Again layout issue placement to beginning of string looks to occur when font fall-back must be processed as with Liberation Serif. But still some differences between OpenGL and GDI rendering.
Can you also attach the document?
Created attachment 129100 [details]
test document with combining examples in Liberation Serif, Symbola, Code2000
The original "Everything is fine until I combinU+20ddU+0364"
And each of these <alt>+X conversion combined characters per font:
Not a HarfBuzz or layout issue as it happens only Mac, looks like a rendering or font fallback issue.
(In reply to Khaled Hosny from comment #10)
> Not a HarfBuzz or layout issue as it happens only Mac, looks like a
> rendering or font fallback issue.
Attaching a clip from current 2017-11-11 master, Windows 10 system with Symbola and Code2000 fonts installed.
In attachment 129100 [details] on Windows 8/8.1/10 builds, font fall back for Liberation Serif picks up Segoe UI Symbol for the 'n' (U+006e) inside a combining circle (U+20dd), with combining superscript e (U+0364)--but then looses its placement and actual glyph to stamp.
Don't know if this is a DirectWrite implementation issue, but is handling the result of font fallback to perform the glyph combining getting lost between D2DWriteTextOutRenderer and ExTextOutRenderer?
Created attachment 137699 [details]
clip from Windows 10 showing bad handling of combining glyphs on fallback to Segoe UI Symbol
Don't think the issue is the Segoe UI Symbol font, rather our mishandling on fallback of the combining glyphs.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Created attachment 146582 [details]
Current status of bug in Liberation Serif, Symbola, and Junicode
I have per comment #14 confirmed this bug as still present in the latest version of LibreOffice:
> Version: 18.104.22.168 (x64)
> Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
> CPU threads: 4; OS: Windows 6.3; UI render: default;
> Locale: en-US (en_US); Calc: group
As the alignment of the characters differed somewhat for me from their appearance in attachment #137699 [details], I have attached a screenshot showing the current status of the bug in a document edited from attachment #129100 [details]—using Junicode in place of Code2000, as I don't have the latter installed.
Yes confirming for the combining character fall-back occurring with Liberation Serif paragraphs, Segoe UI is missplaced to beginning of line.
Symbola and Code 2000 rendering, both containing the combining glyphs, are correctly placed.
Windows 10 Home 64-bit (1803) en-US with Intel HD Graphics 620 and
Version: 22.214.171.124.alpha1+ (x64)
Build ID: afbfe42e63cdba1a18c292d7eb4875009b0f19c0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-10_23:59:43
Locale: en-US (en_US); UI-Language: en-US