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.
Created attachment 123755 [details] Screenshot comparision with and without OpenGL enabled
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.
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
Please attach your C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log
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
Created attachment 124996 [details] OpenGL device log file as requested
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.
It's the assert(-1 != nCharPos) in UniscribeLayout::GetNextGlyphs() that asserts in master.
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.
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...
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.
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.)
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.
The bug title is fairly misleading as there are extremely few (if any) fonts that LO would even use on Windows that would *not* be a "Unicode" font. But I am not bored enough to change it. Also, as seen in discussion above there are several different bugs that the test doc brings up if opened in different ways.
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.
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?
Yes, I had the Gautami font installed on my machine all the while.
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?
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.
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.
Hello Tor, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Changing status to NEW.
** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
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.