Download it now!
Bug 101599 - [EDITING] Inserting certain Unicode combining characters causes text in paragraph to appear corrupted, when using OpenGL
Summary: [EDITING] Inserting certain Unicode combining characters causes text in parag...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: HarfBuzz
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-08-18 19:50 UTC by Michael von Preußen
Modified: 2016-11-28 08:18 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A visual representation of the bug, showing the corrupted display of text caused by the use of a combining character. (45.12 KB, image/png)
2016-08-18 19:50 UTC, Michael von Preußen
Details
Test document with combined characters (8.25 KB, application/vnd.oasis.opendocument.text)
2016-11-24 06:43 UTC, Aron Budea
Details
Screenshot with both layout engines (89.46 KB, image/png)
2016-11-24 07:14 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael von Preußen 2016-08-18 19:50:45 UTC
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.
Comment 1 Buovjaga 2016-09-22 19:55:11 UTC
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.
Comment 2 Michael von Preußen 2016-09-22 23:42:35 UTC
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.
Comment 3 Buovjaga 2016-09-23 17:08:54 UTC
(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?
Comment 4 Michael von Preußen 2016-09-23 17:49:09 UTC
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!
Comment 5 Buovjaga 2016-09-23 17:56:37 UTC
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.
Comment 6 Michael von Preußen 2016-09-23 19:12:50 UTC
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
Comment 7 Aron Budea 2016-11-24 06:43:59 UTC
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
Comment 8 Khaled Hosny 2016-11-24 06:57:42 UTC
(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.
Comment 9 Aron Budea 2016-11-24 07:14:51 UTC
Created attachment 128979 [details]
Screenshot with both layout engines

Sure, here it is.
Comment 10 Aron Budea 2016-11-24 14:00:54 UTC
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.
Comment 11 V Stuart Foote 2016-11-24 15:18:19 UTC
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.
Comment 12 Aron Budea 2016-11-24 16:35:41 UTC
Now I wonder what the difference in the sample is, and why that doesn't work.
Comment 13 Khaled Hosny 2016-11-24 16:42:04 UTC
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.
Comment 14 Aron Budea 2016-11-28 06:27:48 UTC
I opened bug 104212 as advised.
Can this be closed, as the original issue is gone with the new layout engine?
Comment 15 Buovjaga 2016-11-28 08:18:37 UTC
Let's close as fixed.