Created attachment 126897 [details] A visual representation of the bug, showing the corrupted display of text caused by the use of a combining character. Using certain Unicode combining characters in LibreOffice Writer causes text in the same paragraph block as the combining character to appear corrupted, with arbitrary characters replaced with arbitrary other characters. The text itself does not change—if I copy and paste the text to another application, the text I originally typed is preserved—it is merely the display and presentation of the text which is corrupted. To reproduce the bug: 1. Type some text in a LibreOffice Writer document. - Sample text: Everything is fine, until I combine. 2. Type or paste a Unicode combining character into the text. - The characters in the Unicode block U+0300–036F trigger the bug. - Sample text: ⃝ͤ I expect the combining character will be displayed properly, so long as the font supports the character. While this does happen, arbitrary other text in the same paragraph block appears corrupted. Included is a screenshot to demonstrate the bug. The two lines contain the same text, with one exception: the final 'e' on the second line has been replaced by U+0364, COMBINING LATIN SMALL LETTER E. Despite this, the visual display of the text on the second line is substantially different. Of note: - Printing the document or exporting it as a PDF renders the correct text. - Exporting as a JPEG or PNG image renders the corrupted text. - The bug exists with multiple fonts, although which characters appear corrupted for a given block of text varies with each.
Can you copy and paste to a comment the contents of your Help - About LibreOffice? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Locale: en-US (en_US); Calc: group ---- I initially encountered the bug in version 5.2.0.4 (which is what I filed this bug under); it has persisted with my upgrade to version 5.2.1.2. I am adjusting the status back to UNCONFIRMED per the recommendation.
(In reply to Michael von Preußen from comment #2) > Version: 5.2.1.2 > Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 > CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; > Locale: en-US (en_US); Calc: group Thanks! I see you have Render: GL :) What if you disable this setting: Tools - Options - LibreOffice - View - Use OpenGL for all rendering (and restart LibreOffice) Does it make the problem go away?
Well here's a bizarre twist: when I opened LibreOffice to give this a shot, the bug was not present, and upon looking at Option > View, I saw that the OpenGL option was, in fact, unchecked, and About LibreOffice now showed 'Render: default.' I have no idea why this setting magically changed as though in anticipation of your suggestion, but reenabling it caused the bug to reappear, so OpenGL would indeed appear to be the culprit. I'm not sure how this should impact the status of the bug, so I'm leaving it UNCONFIRMED for now. Thank you very much for the assistance!
Great! It is clearly still a bug, we don't want to sweep it under the rug. Now we can look for duplicates. Meanwhile, you could open this file in a text editor and copy & paste the contents to a comment: C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log Then developers can see, what graphics card and driver you use.
DriverVersion: 10.18.13.6839 DriverDate: 6-2-2016 DeviceID: PCI\VEN_10DE&DEV_11C0&SUBSYS_84221043&REV_A1 AdapterVendorID: 0x10de AdapterDeviceID: 0x11c0 AdapterSubsysID: 0x84221043 DeviceKey: System\CurrentControlSet\Control\Video\{3D6DF5E8-3961-410D-84F3-B0858AFC8FDB}\0000 DeviceString: NVIDIA GeForce GTX 660
Created attachment 128978 [details] Test document with combined characters Reproduced with 5.2.3.3 and 5.3 daily build / Windows 7. I created a test document based on the description (replaced the last "e" in the second line with the combining character). It looks wrong in a different way in 5.3 with the common layout engine, so I'll be adding to HarfBuzz regressions metabug, even though it wasn't actually correct before. Version: 5.3.0.0.alpha1+ Build ID: c03c77ef4f46b81cd000ea26c4ef154044322535 CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-17_00:29:08 Locale: hu-HU (hu_HU); Calc: CL
(In reply to Aron Budea from comment #7) > It looks wrong in a different way in 5.3 with the common layout engine, so > I'll be adding to HarfBuzz regressions metabug, even though it wasn't > actually correct before. Do you have a screenshot? I doubt there is anything layout engine-related here.
Created attachment 128979 [details] Screenshot with both layout engines Sure, here it is.
With the common layout the issue exists both with and without OpenGL, and appears somewhat similar to what it looks like in Linux (and has looked like before, too), where there's a circle around the tiny, superscripted e.
On Windows builds, with recent master and new HarfBuzz based text layout, I do not see this effect of the combining character. Version: 5.3.0.0.alpha1+ Build ID: 0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-19_23:33:29 Locale: en-US (en_US); Calc: CL This sample text with Default style's Libreation Serif font... Everything is fine, until I combine. Everything is fine, until I combinU+0364. The combined super script e appends to the n. No other glitch. Same rendering with OpenGL or with default rendering. But if I disable new HarfBuzz based text layout and revert to old DirectWrite based layout I see the issue with OpenGL rendering (again not with default GDI). And on the 5.2.3 release with the old DirectWrite based layout and OpenGL rendering I do see corruption. There also with default GDI rendering I do not. Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US); Calc: group So, this only affects the DirectWrite based "old" layout of OpenGL rendering.
Now I wonder what the difference in the sample is, and why that doesn't work.
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. Either way, I don’t see what is the regression here if pre-HarfBuzz was completely broken, at best this is a new bug, and not likely related to the original one.
I opened bug 104212 as advised. Can this be closed, as the original issue is gone with the new layout engine?
Let's close as fixed.