Bug 98792 - 'Gautami' font rendering incorrectly with OpenGL enabled
Summary: 'Gautami' font rendering incorrectly with OpenGL enabled
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.1.1 rc
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-03-21 07:16 UTC by Ravi
Modified: 2017-09-29 10:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file for unicode rendering issue with OpenGL enabled (8.79 KB, application/vnd.oasis.opendocument.text)
2016-03-21 07:16 UTC, Ravi
Details
Screenshot comparision with and without OpenGL enabled (8.45 KB, image/png)
2016-03-21 07:17 UTC, Ravi
Details
OpenGL device log file as requested (319 bytes, text/plain)
2016-05-12 08:34 UTC, Ravi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ravi 2016-03-21 07:16:22 UTC
Created attachment 123754 [details]
Test file for unicode rendering issue with OpenGL enabled

One of the unicode fonts (Gautami) displays incorrectly in version 5.1.1.1c. It was OK in version 5.0.1.3. Attached screenshots of correct and incorrect display and a minimal test file. There may be other similar fonts with the same problem; I have not checked others.
Comment 1 Ravi 2016-03-21 07:17:21 UTC
Created attachment 123755 [details]
Screenshot comparision with and without OpenGL enabled
Comment 2 Ravi 2016-03-21 07:49:33 UTC
Checked with latest release 5.1.1.3. In this version, OpenGL is disabled by default, even though the checkbox to enable it is selected. Checking the option to enable OpenGL even if blacklisted results in the issue coming back. So by virtue of blacklisting, this issue does not happen in 5.1.1.3 - not sure why the blacklist is active in this case and whether this is the final solution. Perhaps somebody with more insight could disposition this bug report based on this information.
Comment 3 Buovjaga 2016-03-25 16:02:17 UTC
It is because your graphics card / its driver does not support enough OpenGL features.
The info for your driver is in:
C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log
Comment 4 raal 2016-05-12 06:35:22 UTC
Please attach your C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log
Comment 5 Ravi 2016-05-12 08:31:29 UTC
Contents of the file C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log :

DriverVersion: 10.18.14.4332
DriverDate: 11-20-2015
DeviceID: PCI\VEN_8086&DEV_0A16&SUBSYS_397817AA&REV_09
AdapterVendorID: 0x8086
AdapterDeviceID: 0x0a16
AdapterSubsysID: 0x397817aa
DeviceKey: System\CurrentControlSet\Control\Video\{3AB2939D-3B31-47B9-9450-A24E9B0E4163}\0000
DeviceString: Intel(R) HD Graphics Family
Comment 6 Ravi 2016-05-12 08:34:12 UTC
Created attachment 124996 [details]
OpenGL device log file as requested
Comment 7 Tor Lillqvist 2016-05-13 13:29:22 UTC
This bug seems to be fixed in the 5.1 branch, i.e. the fix will be in 5.1.4.

Sadly, the document causes an assertion failure in a fresh master build.
Comment 8 Tor Lillqvist 2016-05-13 13:39:11 UTC
It's the assert(-1 != nCharPos) in UniscribeLayout::GetNextGlyphs() that asserts in master.
Comment 9 Tor Lillqvist 2016-05-16 11:50:51 UTC
Interesting that I hit the assertion only when passing the document name on the soffice.exe command line. If I open the document through Control-O, then it works fine. Weird.
Comment 10 Tor Lillqvist 2016-05-16 13:52:08 UTC
Ah, I now notice that the reason I don't see the crash in my 5.1 tree is because it has been built with --enable-symbols only, not --enable-debug (or the even stronger --enable-dbgutil), and thus assertions are ineffective. Sigh. If I add a "manual" conditional SAL_DEBUG, I do see that nCharPos is -1 at the location in question. So the crash is not specific to the master branch, which I guess is good at least...
Comment 11 Tor Lillqvist 2016-05-16 13:52:16 UTC Comment hidden (obsolete)
Comment 12 Tor Lillqvist 2016-05-16 13:55:38 UTC
I wonder if that assertion should simply be dropped... Cant say I understand the code that much... but it seems to cope fine with nCharPos being -1 at that point.
Comment 13 Tor Lillqvist 2016-05-16 14:34:35 UTC
Oddly enough the rendering of the document is affected by whether one passes the document file name on the command line, or opens it from the GUI. In the first case it looks correct, not the second case. (This assuming one disables the assertion first.)
Comment 14 Tor Lillqvist 2016-05-24 10:09:32 UTC
This is a quite complex bug in the sense that there are several things that are more or less buggy that are involved... Anyway, one thing I discovered was that if I do install the "Telugu Supplemental Fonts" in my Windows 10 (so that I get the Gautami font), then I see the same (correct) rendering regardless whether I pass the document name on the command line or open it from LibreOffice.
Comment 15 Tor Lillqvist 2016-05-24 12:56:21 UTC Comment hidden (obsolete)
Comment 16 Commit Notification 2016-05-25 08:40:56 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f6f409c7a2355f0d9c2267856cb24694cfc25e6

tdf#98792: Add the 'Nirmala UI' font as fallback for 'Gautami' for Telugu

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Tor Lillqvist 2016-05-25 08:42:44 UTC
Note that the above commit only adds Normal UI to the VCL.xcu, it does not "fix" all aspects of this bug.

Ravi, do you have the Gautama font installed on your machine?
Comment 18 Ravi 2016-05-25 09:35:15 UTC
Yes, I had the Gautami font installed on my machine all the while.
Comment 19 Tor Lillqvist 2016-05-25 09:37:33 UTC
Oh, and you still saw problems, that is very odd. For me everything looked fine as soon as I installed the Gautami font. This is on Windows 10, what Windows version do you have?
Comment 20 Ravi 2016-05-25 09:51:10 UTC
Yes, the problem was there with Gautami always installed. I still see this if I force enable OpenGL rendering, I am now on LO 5.1.1.3 release. Windows version 8.1, 64-bit. Not yet checked later releases. Let me know if there is something specific you would like to me check.
Comment 21 Commit Notification 2016-05-25 12:00:50 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5f459af600597d3508676252b23ff8b5e00427dd

tdf#98792: This assertion is not needed

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Xisco Faulí 2016-09-26 10:23:12 UTC
Hello Tor,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Changing status to NEW.
Comment 23 Xisco Faulí 2017-09-29 08:49:48 UTC Comment hidden (obsolete)
Comment 24 Ravi 2017-09-29 10:32:58 UTC
Checked with latest version LO 5.4.1.2 (x64), Win 8.1. In this version, it displays fine even with OpenGL enabled. Also confirmed that the GL driver is not blacklisted ("GL is currently enabled" shown). Not sure in which version it had actually got fixed. In any case, marking this bug as RESOVLED-WORKSFORME as per instructions, since it seems fixed in current version.