Description: When an emoji is placed next to a character from a different script (such as Latin or Cyrillic), the emoji's font assignment may be ignored, and a fallback font is used instead. This happens even when an emoji-supporting font is explicitly assigned. The behavior depends on which font assignment slot (e.g., "Western text font" or "Asian text font") the emoji font is applied to, and what script is used in the adjacent characters. This results in inconsistent and unintuitive font application behavior, breaking user expectations and making emoji styling unpredictable. Steps to Reproduce: 1.Insert any emoji (e.g., 🇯🇵🗾). 2.Assign an emoji-supporting font (e.g., Segoe UI Emoji) to either the Western or Asian text font slot. 3.Reset formatting before and after the emoji using Ctrl+M (optional). Do not reset the emoji itself. 4.Add a character next to the emoji from a different script (e.g., Latin, Cyrillic, Hebrew, Arabic). 5.Observe whether the emoji is displayed using the assigned font or not. Actual Results: The assigned emoji font is ignored, and fallback rendering occurs depending on the surrounding characters’ scripts and the font slot used. Examples: - If the emoji font is assigned via the Asian text slot, and the emoji is adjacent to Latin text -> fallback occurs. - If the emoji font is assigned via the Western text slot, and the emoji is adjacent to CJK text -> fallback occurs. Expected Results: The emoji should always be rendered using the font that was explicitly assigned to it, regardless of surrounding character scripts. Reproducible: Always User Profile Reset: Yes Additional Info: - This is not limited to any specific emoji; all tested emoji showed this behavior. - The issue does not seem to occur when adjacent characters belong to the same script associated with the font slot used (e.g., CJK for Asian, Latin for Western). - If both characters surrounding the emoji are from the expected script (e.g., both CJK), the assigned emoji font works. - This behavior affects all tested emoji-supporting fonts: - Segoe UI Emoji (v1.51) - Twemoji Mozilla (v0.70) - Noto Color Emoji (v2.047) - Noto Emoji (v2.001) - BabelStone Flags (v4.13) - It is currently unknown whether this issue is specific to Windows or also occurs on other platforms such as macOS or Linux. - The issue makes emoji styling highly dependent on adjacent text content and font slot configuration, which is not intuitive and may be considered a rendering bug from a user perspective. Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: fef47a8bcc8531e69ccea29f2db5929741e66a3e CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
There is no unique font assignment in ODF made for Emoji, nor does LibreOffice implement such. => NAB Otherwise the Emoji handling in LibreOffice is actually pretty reliable. All Emoji are just an ordinary Unicode glyph assignment. A font may cover the glyph or it may not--most don't and Emoji then depends on os/DE provided fallback to select. Regardless of the surrounding span of text. That fallback change when a text span receives a font change bcz of LO's ODF Western/CJK/CTL detection implementation is expected. Doing otherwise would be non-compliant and supporting specific font assignment to Emoji would require ODF extension. Inclined toward => WF if requested as an enhancement.
I see, thank you very much for the clear and thorough technical explanation. I hadn’t fully understood the ODF specification before, so this has been very informative and educational for me. I'd like to consider this resolved as "Not a bug", but before closing the report, I’d like to confirm one thing: As far as I understand, Emoji themselves are not inherently tied to any specific language. However, when an Emoji font is assigned under the "Western" font setting, the Emoji is treated as part of Western text; similarly, when assigned under the "Asian" font setting, it is treated as part of Asian text. Is this understanding correct?
(In reply to Takenori Yasuda from comment #2) > As far as I understand, Emoji themselves are not inherently tied to any > specific language. However, when an Emoji font is assigned under the > "Western" font setting, the Emoji is treated as part of Western text; > similarly, when assigned under the "Asian" font setting, it is treated as > part of Asian text. > > Is this understanding correct? Yes that is correct, specific glyphs follow assignment of the text span (by Paragraph Style) they fall in. The Unicode are locale/language neutral and mostly fall in the Unicode "Miscellaneous Symbols and Pictographs" (1F300-1F5FF), "Emoticons" (1F600-1F65F), and "Supplemental Symbols and Pictographs" (1F910-1F9FF) all from the Unicode Supplemental Multilingual Plane SMP, with a few common glyphs taken from "Miscellaneous Symbols" (2600-26FF) and "Dingbats" (2700-27BF) from the Unicode Basic Multilingual Plane BMP (In reply to V Stuart Foote from comment #1) And, thinking a bit on it, some measure of control by locale could be achieved by adding common fonts with Emoji coverage to the font substitution lists in VCL.xcu. But, we'd still need to extend ODF and now specify font assignment for LATIN_EMOJI, CJK_EMOJI, CTL_EMOJI in the config and then handle it internally in VCL. But which font(s) and would it really matter. Ultimately fallback selection is dependent on user's installed font collection, or their os/DE support by locale. LO would lack any granular control. In fact we stopped delivering font to support Emoji and dropped our own Emoji picker as os/DE support had improved. Just not seeing much of a requirement to try to localize font use for Emoji.
Thank you very much not only for answering my question, but also for providing such detailed and easy-to-understand technical background, historical context, and additional information. Thanks to your explanations, all the questions I had lingering in my mind regarding emoji and font behavior have been completely resolved! With this, I will mark this report as RESOLVED / NOTABUG.