Created attachment 121230 [details] Highlight all the text to see the missed cursor position In Windows, using the default font, some unicode characters cause the cursor to be positioned in the wrong place. Windows 7, LO 5.0.3 To reproduce: Using the default Liberation Serif font, type some text containing the unicode subscript 2 (₂) somewhere in the middle. The cursor no longer shows up at the end of the line. Highlighting the text also stops short of the end of the line. Copying and pasting text containing the unicode also behaves strangely, inserting line breaks in strange places. Again, the unicode character can not be selected because the cursor position is wrong. Fix: Switch to "Linux Libertine" font. I do not see this in Linux.
I repro from scratch (by pasting ₂). However, 4.3 does not have the problem. Could not find duplicate reports. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: 014633f83e44ae8ba33087b6f38e8e253e281969 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-15_06:21:44 Locale: fi-FI (fi_FI) 4.3.0.1
This seems to have begun at the below commit. Adding Cc: to Tor Lillqvist; Could you possibly take a look at this one? Thanks 7f0371ad242095657660bb4862bcdfa4a28b4e2c is the first bad commit commit 7f0371ad242095657660bb4862bcdfa4a28b4e2c Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Aug 11 23:27:51 2015 -0700 source 4667db065d34193d99bce82f7e8f3b20a03ecade source 4667db065d34193d99bce82f7e8f3b20a03ecade author Tor Lillqvist <tml@collabora.com> 2015-08-12 05:18:50 (GMT) committer Tor Lillqvist <tml@collabora.com> 2015-08-12 06:14:20 (GMT) commit 4667db065d34193d99bce82f7e8f3b20a03ecade (patch) Drop SimpleWinLayout
No need to say "Unicode characters"; all characters that LibreOffice handles are Unicode...
I wonder what the desired behaviour is when text contains a character that simply does not exist in the font used or in any of the (mysterious?) automatic list of fallback fonts that LibreOffice uses.
Further investigation seems to show that there are problems both when using "glyph caching" and not (SAL_DISABLE_GLYPH_CACHING=1), and when using OpenGL and not. Different problems, though. In one case the ₂ shows up just fine (being picked through glyph replacement from another font), in the other case it doesn't show up and instead you get a mis-rendered mess with two small black boxes. In both cases the glyph widths as used by cursor movement don't match the actually rendered glyphs. In short, a sorry mess. Sigh.
Adding handling of the pRectToErase parameter also to UniscribeLayout::DrawTextImpl() takes care of the black boxes in the SAL_DISABLE_GLYPH_CACHING=1 SAL_FORCEGL=1 case. But the caret ("text insertion cursor") movement is still confused by the glyph replacement in this case (and the others).
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7368803e540d530a157d3c4234ca5428a44cbc4a tdf#96420: Avoid drawing ugly black boxes on top of replacement glyphs 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=bddfc8b684ec5b730ea3791a534259516fd46629&h=libreoffice-5-1 tdf#96420: Avoid drawing ugly black boxes on top of replacement glyphs 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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4622689fad7ddff72cd08da9611ccfacdb0aa7bd tdf#96420: Re-introduce SimpleWinLayout 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=bf417a38c401868bb246e846d4c697cf840771e1&h=libreoffice-5-1 tdf#96420: Re-introduce SimpleWinLayout It will be available in 5.1.1. 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.
Thanks for the fix Tor =)