#1043 Some characters are not displayed in the OmegaT UI

[Jean-Christophe Helary]

It looks like some characters are not displayed in the OmegaT UI, regardless of the font used.

I tried to use an emoticon (U+1F607 - 😇) in the "match prefix" preference and it was not displayed in the preference UI, and was not displayed either in other prefs (paragraph delimiter, for ex). It is not displayed in the segment display either.

[Hiroshi Miura]

The emoicons are placed on Supplementary Multilingual Plane in Unicode standard table.
It is expressed in Surrogate-pair , 2 Character objects, in Java UTF-16. It may be a reason why it does not work properly.

[Jean-Christophe Helary]

Do you think there is an easy way to fix this ?

[Hiroshi Miura]

The cause is a font.

Very limited font can display emoicons on Java.

Many applications such as a web browser replaces emoji char in Unicode to graphics.
OmegaT just display it with java font.

Please see an attachment. That is OmegaT screenshot that use a special custom theme, the feature recently included in Nightly build.

I uses "Dialog" font that has a emoicons to demonstrate it.

I uses Linux for development, I've installed many fonts but only 11 font can display emoji.

DejaVu Sans
DejaVu Sans Condensed
DejaVu Sans Condensed Oblique
DejaVu Sans Oblique
Dialog
DialogInput
Monospaced
Noto Color Emoji
SansSerif
Serif
Unifont Upper

Number of fonts=11/2659

[Hiroshi Miura]

You can try a plugin attached which configured to use DejaVu Sans on Nightly OmegaT, and please download and install DejaVu Sans font on your OS.
https://dejavu-fonts.github.io/Download.html

preference -> appearance -> theme
change theme to Flat Round Dark
then Project -> restart

OmegaT team can bundle a font such as DejaVu Sans as a fallback, and it can check system fonts when launched and if there is no good font, use fallback one for input dialog.

Here is a short scratch program to detect a font which can display emoicons.

import java.awt.Font;
import java.awt.GraphicsEnvironment;

class Scratch {
    Font[] fonts = GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts();

    Scratch(String as[]) {
        String dspchr = "\uD83D\uDE03";
        int fnumber = fonts.length;
        int sp, n = 0;

        for (int i = 0; i < fnumber; ++i) {
            if (!fonts[i].canDisplay(dspchr.codePointAt(0))) continue;
            String fns = fonts[i].getName();
            if (-1 != fns.indexOf("bold")) continue;
            if (-1 != fns.indexOf("Bold")) continue;
            if (-1 != fns.indexOf("italic")) continue;
            if (-1 != fns.indexOf("Italic")) continue;
            sp = fns.indexOf(".plain");
            if (-1 != sp) fns = fns.substring(0, sp);
            sp = fns.indexOf(" Regular");
            if (-1 != sp) fns = fns.substring(0, sp);
            sp = fns.indexOf("-Regular");
            if (-1 != sp) fns = fns.substring(0, sp);
            System.out.println(fns);
            ++n;
        }
    }

    public static void main(String[] args) {
        new Scratch(args);
    }
}

[Hiroshi Miura]

The plugin project is https://github.com/miurahr/omegat-round-theme
I've modified the plugin as follows;

diff --git a/src/main/java/tokyo/northside/omegat/theme/FlatRoundDarkLaf.java b/src/main/java/tokyo/northside/omegat/theme/FlatRoundDarkLaf.java
index 0720277..692fd11 100644
--- a/src/main/java/tokyo/northside/omegat/theme/FlatRoundDarkLaf.java
+++ b/src/main/java/tokyo/northside/omegat/theme/FlatRoundDarkLaf.java
@@ -29,7 +29,9 @@ import org.omegat.gui.theme.DefaultFlatTheme;
 import javax.swing.UIDefaults;
 import javax.swing.UIManager;
 import javax.swing.border.MatteBorder;
+import javax.swing.plaf.FontUIResource;
 import java.awt.Color;
+import java.awt.Font;
 import java.awt.Insets;


@@ -94,6 +96,7 @@ public class FlatRoundDarkLaf extends FlatDarkLaf {
         defaults.put( "ScrollBar.track", new Color( 0xe0e0e0 ) );
         defaults.put( "TabbedPane.tabSeparatorsFullHeight", true );
         defaults.put( "TabbedPane.selectedBackground", Color.GRAY );
+        defaults.put("TextField.font",new FontUIResource(new Font("DejaVu Sans",  Font.PLAIN, 12)));

         return defaults;
     }

OmegaT can do similar thing on DefaultFlatTheme.java

[Hiroshi Miura]

It is not displayed in the segment display either.

This is also a font issue. I've push the Pull-Request to allow users to select a proper font.
https://github.com/omegat-org/omegat/pull/117

[Hiroshi Miura]

Attached file is a test source for trasnlation that has emoticons.
You can check your font can display emoji on OmegaT.

[Aaron Madlon-Kay]

I'm sorry, Hiroshi, but I think you're barking up the wrong tree.

First, Java Swing has limited text rendering capabilities and simply can't render a lot of emoji (especially composed ones like ZWJ sequences or region flags). It doesn't support the Apple Color Emoji font, so on Mac it will never give you the same rendering as native applications.

For single-codepoint emoji, if you have a font that provides a glyph for that emoji (suggstion: Noto Emoji but not Noto Color Emoji on Mac, as it is not supported), then in theory Swing should manage to fall back to that font, but in practice it often doesn't. For those cases in the Editor pane we have the Aggressive Font Fallback feature, which will go character-by-character and attempt to locate and apply a supporting font.

Outside of the Editor pane, we would have to apply the Aggressive Font Fallback feature to literally every textbox in the application. This is super invasive and I don't really want to do it. If someone wants to look into a nice way to do it, go ahead.

One problem with Aggressive Font Fallback is that it is currently broken on Java 11; see [#1051].

Hiroshi's strategy to address this issue is just not a good solution:

1. It doesn't solve any case that Aggressive Font Fallback wouldn't already solve
2. It suffers from the same brokenness on Mac as Aggressive Font Fallback ([#1051])
3. It is actually worse than Aggressive Font Fallback because it suggests that you would use the emoji font as your default font for everything in the Editor. That just doesn't make sense.

4. It's bad UI/UX:

   You should not need to choose a particular default font to get particular glyphs to show; that is supposed to be handled by font fallback.
   If we accept that we have to do extra work because Swing sucks at font fallback, the logical result of that is the Aggressive Font Fallback feature (where only codepoints that need it get manual fallback), not making the user choose a particular font that prioritizes a particular set of codepoints.
   Why emoji? Why do they warrant a special feature in the Font preferences? What about any other set of codepoints that Swing fails at, like Egyptian Hieroglyphs or Mathematical Alphanumeric Symbols?

I think this will only be fundamentally solved by either Java Swing getting major updates (probably not happening) or us porting OmegaT to a different UI framework like SWT.

[Jean-Christophe Helary]

Thank you very much @miurahr9 and @amake for the discussion and the attempts at fixing this. It is definitely not a priority as it does not impair any work in OmegaT. I'm fine with closing the issue.

[Aaron Madlon-Kay]

It's a legitimate issue, so I am happy to keep the ticket open.

[Hiroshi Miura]

When we can find a way to detect a good font or fix Aggressive Font Fallback on Java 11, we can set it UIManager.put('TextField.font', font) in themes.
I'd like to address to [#1051].

[Hiroshi Miura]

FYI: recent OpenJDK accept an interesting patch to support Emoji.
JDK-8263583

This requires adding support for color (ARGB) glyphs to glyph rendering pipeline at all its stages (generation, storage and blitting). Emoji glyphs on macOS are provided by 'Apple Color Emoji' system font. It cannot be rendered with Core Graphics API, Core Text should be used instead. As the font is a bitmap one, and it's not scaled proportionally with font size, special measures should be taken to perform its correct sizing during rendering and metrics calculation.

8263583: Emoji rendering on macOS

[Hiroshi Miura]

FYI: Emoji rendering on Linux is not fixed yet
JDK-8268806

[Hiroshi Miura]

After complete the implementation of [#1069], we can put images on editor panes.

Here is a simple idea that we can put emoicon image with <img src="data:base64,brabra"> for alternative of emoji character code.

[Hiroshi Miura]

Now this looks working on OmegaT nightly on Java 11 on Linux. See attachment.
@brandelune Could you try Nightly with Java 11?

I think it has been solved by #1051 resolution.

[Hiroshi Miura]

OpenJDK 21 introduce Unicode Emoji Properties API.
https://github.com/openjdk/jdk/pull/13006

[Hiroshi Miura]

The proposal is merged and released in JDK21.

JDK21 has Unicode EMOJI property
https://jdk.java.net/21/release-notes#JDK-8303018

Unicode Emoji Properties (JDK-8303018)
core-libs/java.lang
The following six new methods are added to java.lang.Character for obtaining Emoji character properties, which are defined in the Unicode Emoji Technical Standard (UTS #51) :

• isEmoji(int codePoint)
• isEmojiPresentation(int codePoint)
• isEmojiModifier(int codePoint)
• isEmojiModifierBase(int codePoint)
• isEmojiComponent(int codePoint)
• isExtendedPictographic(int codePoint)

[Hiroshi Miura]

Ref: Unicode Standard, Emoji Specification https://unicode.org/reports/tr51/

[Hiroshi Miura]

We can advice to users to use Java 21 or later when user want to use EMOJI for any configuration.
Unfortunately, emoji check is supported in Java 21 or later.

[Hiroshi Miura]

We can define regex to identify emoji in Java 21 or later.

https://jdk.java.net/21/release-notes#JDK-8305107

Emoji Related Binary Properties in RegEx (JDK-8305107)
core-libs/java.util.regex
Emoji-related properties introduced in (JDK-8303018) can now be used as binary properties in the java.util.regex.Pattern class. One can match characters that have Emoji-related properties with the new p{IsXXX} constructs. For example,

Pattern.compile("\p{IsEmoji}").matcher("🉐").matches()
returns true.

[Hiroshi Miura]

Java 17 on macOS seems supports to show emoji character, but windows and linux is not.
I'd like to postpone milestone to future release.