https://bugs.documentfoundation.org/show_bug.cgi?id=92940
V Stuart Foote <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from V Stuart Foote <[email protected]> --- @tommy27, * On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 1d5767c6e464b914812867aac5c3ccd0745dd1ea CPU Threads: 8; OS Version: Windows 6.19; UI Render: default (and GL); TinderBox: Win-x86@42, Branch:master, Time: 2016-03-20_00:02:24 Locale: en-US (en_US) Continue to see this, but beleive there are two aspects to mishandling of the :<emoji>: substitutions: 1. method of launch 2. support for non-BMP codepoints by language in use I think they are both related to incorrect font handling and need for fallback font selection both with and without OpenGL (even the new DirectWrite/GDI+ based layout on MS Windows). Affect by method of launch shows up as in bug 71603, where launching form the StartCenter does not "enable" functional font handling. But you do get functional font behavior if using CLI (e.g. "swriter.exe %USERPROFILE%\documents\testDocument.odt") or using the OS file association and launch from Windows Explorer. And at that point when launched, fallback and emoji autocorrection ends up "enabled". Which can be confirmed by checking the list of defined "emoji" in Tools -> AutoCorrect -> AutoCorrect Options dialog. If "enabled" and working, it will show a character for each :<emoji>: substitution. But the glyphs all look to be drawn from system font--so Seoge UI on Windows Vista, 8, 8.1 and 10. If not working--many of the :<emoji>: entries will show a place holder character. But even when "enabled" in the AutoCorrect Options list, there is another issue in font handling that has been preventing display on the document canvas of emoji glyphs in the selected font. Either a placeholder character is rendered, or the cell that should hold the glyph gets no character and adjacent characters collapse over the space. Happens even for paragraphs using fonts that shouldn't need fallback for emoji glyps that are defined for SMP codepoints (i.e. > U+FFFF). Really seems they both are related issues in font handling for deciding that a font has codepoint coverage and its glyphs should be used for the given language of a document or a paragraph. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
