https://bugs.documentfoundation.org/show_bug.cgi?id=166925

            Bug ID: 166925
           Summary: FORMATTING: Emoji font assignment is ignored depending
                    on the surrounding character scripts, causing
                    unexpected fallback
           Product: LibreOffice
           Version: 25.2.4.3 release
          Hardware: x86-64 (AMD64)
                OS: Windows (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: [email protected]
          Reporter: [email protected]

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to