Created attachment 119609 [details] Result Step to reproduce. Just write a text With Linux Biolinum font Italic and result is not correct All is fine is OpenGL is disabled LO 5.0.3.1 x32 & W10 x64
Ubuntu 15.04 x 64 LibreOffice 5.0.2.2 Cannot reproduce. Looks clean to me.
Could repro with OpenGL, but only in 5.1. 5.0.2 is fine. I have severe problems with 5.1 OGL enabled, so might be tied with those. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI) Version: 5.1.0.0.alpha1+ Build ID: 186f32f63434e16ff5776251657f902d5808ed3d TinderBox: Win-x86@39, Branch:master, Time: 2015-10-16_09:42:47 Locale: en-US (fi_FI)
I did my tests with latest 5.0.3.1. I Don't remember having such problems with 5.0.2.2
Created attachment 119676 [details] Impress problem
I have some problems with font rendering also in Impress. See the attachment. First slide, the text, second slide what I see.
Chasing summary to be more generic. The problem exists not only for that italic font, but it is visible (not quite so obvious, though) also for instance with Gentium Basic and plain lower-case characters. I think the issue here is that the GraphiteWinLayout::DrawTextImpl() function draws each glyph using a separate call to ExtTextOutW(), and that mishandles anti-aliased glyphs (alpha), somewhat like described in the long comment in WinLayout::DrawText(). The irony here is of course that in the case of Graphite fonts, and OpenGL, we are exactly in that code block in WinLayout::DrawText(), that does some acrobatics in order for anti-aliasing to end up looking correct. But from that code block we then call DrawTextImpl(), which in the case of GraphiteWinLayout, itself runs into the same (?) problem as the calling code wants to avoid on a higher level, as it draws each glyph separately, and subsequent glyphs might overwrite the rightmost pixels of the earlier one. Or something like that.
I came up with a fix that seems to help. I changed the interface of the DrawTextImpl() virtual member function so that instead of being called once to draw a run of text, it might draw just a part of the run, and expect to be called repeatedly to draw the whole text. The GraphiteWinLayout implementation then takes advantage of this, the end result being that it draws one glyph at a time into the DC that corresponds to the bitmap allocated in the caller (WinLayout::DrawText), and the caller draws using that bitmap as an alpha mask into the actual destination each time. Sounds complicated and silly (the same texture being drawn over and over again) but it seems to work. But I need to work on it a bit more to see if I can do it in a simpler way.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=61085083e4a5060ba7e2135818264d63c6da13c2 tdf#95054: Make sure glyphs alpha blend properly in the Graphite+OpenGL case 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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac04051a3565bb5cde904da9a84b6e22443cf8b5&h=libreoffice-5-1 tdf#95054: Make sure glyphs alpha blend properly in the Graphite+OpenGL case It will be available in 5.1.0.2. 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.