On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: c81eddbb20c84280aa64c712e34c829380b24527 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-22_04:19:03 Locale: en-US (en_US) with or without OpenGL enabled. Have lost the SEP Unicode codepoints above FFFF both in documents and in the special character dialog.
For now Windows only, but can someone check Linux and OS X. Attaching test document authored on Windows with both Symbola and Code 2001 fonts installed to a Windows 10 Pro 64-bit en-US (10586 build) system. http://cgit.freedesktop.org/libreoffice/core/log/?id=fefd1221be844a033e409a18e05e8c6e98f6d1a7&qt=range&q=6b65a0e83c4798f117be61af91dbaebdc85e94b7..c81eddbb20c84280aa64c712e34c829380b24527 Unfortunately several pieces in movement in this range... sorry. Michael S.'s work on i18n Unicode support for StarMath Tor's work reintroducing SimpleWinLayout (bug 96420) Chris' work on FontFamily Also, somewhere in the mix of this and handling fallback font we have lost ability to handle the SEP and higher plane codepages in the Special Symbol dialog. =-biset results-= OK 22e5170af74c635cf55d089f97946b6dc86f82ad - 2016-01-06 813a319fe836d1ed1c967928bc044643d0b4c07d - 2016-01-12 c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c - 2016-01-13 70ea14baf7d43c00f73807bce13629ca25320558 - 2016-01-14 f0841c6c86c8c8403eb1d78a1bd43a8adac75e3a - 2016-01-15 0174562fa9e49bf989a571c6ccd51e558109b561 - 2016-01-16 49b5eed56c470975927bb7b0328337ab8a76a910 - 2016-01-17 000df1832b54ba8f48c7f1c4c1cd92b70f6402da - 2016-01-18 447c313586e9b36acff393feae15f5e1b63861ae - 2016-01-19 029ce852c2f67e06d60e0ce50fff936c8e2ce9f4 - 2016-01-20 6b65a0e83c4798f117be61af91dbaebdc85e94b7 - 2016-01-21 Bad c81eddbb20c84280aa64c712e34c829380b24527 - 2016-01-22 3fc292f7b32f30b98dad208eb03e086b927d38a2 - 2016-01-23 49b5eed56c470975927bb7b0328337ab8a76a910 - 2016-01-24
Created attachment 122194 [details] odt with multiple fonts and both BMP and SEP codepage use
On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 9784ff3d878eaa21491fbd779e57d7d4710f5449 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-30_01:31:57 Locale: en-US (en_US) @Tor, I know Chris has been working on this, and fallback fonts for bug 71603, but with this latest build seem to be getting different renderings of the Unicode BMP and SEP depending on OpenGL rendering. With OpenGL enabled, the font metrics are garbled, OpenSymbol is especially bad--but also, glyphs from the SEP codepoints are not being rendered in their respective fonts. See attached. As to bug 71603, no improvement to the fallback font handling for fonts missing BMP or SEP codepoints. But weird in that autocorrect entering emoji in paragraph with Symbola, e.g. :kimono: works, but for Segoe UI Emoji paragraph it does not and I get an undefined glyph.
Created attachment 122290 [details] glyph rendering affected by OpenGL
The Special Characters dialog is also affected. With OpenGL disabled, viewing Symbola font for codepoints in the SEP, glyphs are rendered. But again weird in that Segoe UI Symbol or Emoji do not show codepages beyond the BMP (display ends at FFFF). And a seeming OpenGL glitch, when enabled the SEP codepages for Symbola all end up with a pair of place holder glyphs.
On Windows 10 Pro 64-bit (build 10586) en-US with Version: 5.2.0.0.alpha0+ Build ID: 2b60321b21ff9ada64576f5711950b616b8a25ba CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-02-12_23:49:18 Locale: en-US (en_US) and Version: 5.1.1.1 Build ID: c43cb650e9c145b181321ea547d38296db70f36e CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Locale: en-US (en_US) Work around the issue of bug 71603 using CLI or OS to launch swriter directly, opening the above attachment 122194 [details] or attachment 108223 [details] (from bug 85109) With OpenGL disabled the SEP, and also Plane 2 (from CJK Unified Ideographs Extension B block in Sim-sum) glyphs are rendered and fallback occurs. With OpenGL rendering enabled SEP and Plane 2 glyphs are not rendered--fall back does not occur. So this really looks to be an OpenGL only font glitch, but just Windows??? Some other confirmation would be nice. Adding to bug 93529 =-aside-= filed bug 97839 for the Special Character dialog... Although with OpenGL disabled, when SEP or higher planes are exposed by OS or CLI launch, the Special character dialog is having trouble with characters in the paste preview bar, not composing the multi-byte codepoints.
What's SEP?
(In reply to Tor Lillqvist from comment #7) > What's SEP? /me embarrassed... Make that Supplementary Multilingual Plane (SMP), aka Unicode Plane 1 And where we now draw many autocorrect substitution entered Emoji glyphs from, so pretty much all LO users affected.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=73443fd278811837650160482c34c15e8830f0d3 tdf#97319: Handle surrogate pairs in glyph caching for 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.
The above commit makes the glyphs show up, but they are still rendered with incorrect widths / at incorrect locations (all on top of each others).
Remaining problem could be related to glyph fallback. Did we lose glyph fallback completely now for SimpleWinLayout?
(In reply to Tor Lillqvist from comment #11) > Remaining problem could be related to glyph fallback. Did we lose glyph > fallback completely now for SimpleWinLayout? The later issues of bug 71603? Chris's cmnts 10 - 13 ref Miklos's work on bug 92505 Unfortunately, I'm waiting for a current Windows TB to roll to be able to test this as well as the DiretWrite patch for bug 97171 Thanks though, I know dropping Uniscribe and now having to fix SimpleWinLayout has been a pain.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e3d0e8069e3bd82831b0070f70052f2202180192 tdf#97319: Give up on caching non-BMP 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=c54310c6b0f14a649ab3d290c012fff2fab86d85&h=libreoffice-5-1 tdf#97319: Give up on attempting to cache non-BMP glyphs for SimpleWinLayout It will be available in 5.1.3. 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.
*** Bug 98709 has been marked as a duplicate of this bug. ***
Any input here ? can we close it ? =) ultimately glyph fallback is a bit of a horror here I think ...
On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 157469896ef56720f33676222b95e81c04ab5c72 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-04-06_20:10:15 Locale: en-US (en_US) We now get glyph rendering now for SMP with OpenGL rendering via DirectWrite, as well for SMP with default rendering in SimpleWinLayout. So, probably OK to close this issue. There remains a noticible difference in rendering the SMP glyps remains between OpenGL DirectWrite and default rendering. Almost as if with OpenGL and DirectWrite the block holding the glyph is off-center and the glyph is clipped. Strangely, with OpenGL the top edge and left edge of glyps with SMP codepoints are clipped, the BMP codepoints seem unaffected. With default rendering it looks like positioning of both BMP and SMP glyphs are good. Also, the issues of bug 71603 continue to impact this. When launched via StartCenter no fall-back font assignment occurs. Must launch directly via command line "swriter.exe <path\filename.odt>" to get viable font substitution. So, assume there some difference in method of opening with a locale established, or not, impacts the available font ranges.