About recent commits to have FLTK handle properly all emojis

[Manolo]

Hi fellow developers,

I'd like to explain here recent commits about emoji support by FLTK.

FLTK now supports the input of emojis to FLTK text widgets using the character 

palette each OS proposes to ease the task of identifying the desired emoji.

I believe there's little doubt this is a good addition to FLTK considering
how popular emojis have become.

The emoji palette opens under macOS typing cmd+ctrl+space, under Windows with
Windows_key+dot, under Linux with Windows_key+dot+space.

Many emojis correspond to single Unicode points (example: 😄). FLTK adequately
draws them in text strings and edits these strings. In contrast,
some emojis are more complicated and created challenges to FLTK even though
when the user selects one of them in the emoji palette nothing suggests
this challenge.

One such case is for composed emojis where the desired drawn emoji is expressed
in Unicode by 3 successive codepoints where the 2nd is U+200D "zero-width joiner".
Example: the "woman pilot" emoji (👩‍✈️) is encoded by U+1F469 "woman" +
U+200D "zero-width joiner" + U+2708 "airplane". Furthermore, it seems that
some platforms add a 4th codepoint at the end: U+FE0F "emoji variation selector".
A unicode-compliant program should draw these 3 (or 4)
consecutive codepoints as a single drawable character.

Another challenge occurs with how Unicode encodes skin color.
Example: the "woman with dark skin" emoji (👩🏿) is encoded by U+1F469 "woman" +
U+1F3FF "emoji modifier fitzpatrick type 6".

For FLTK text widgets to handle correctly these challenges, I have extended
to the Windows and macOS platforms the procedure already used under X11/Wayland
by function fl_draw(const char*, int):
- the width of a string containing a single unicode point is computed and
memorized in the table of character widths;
- the width of a string containing several unicode points is computed as
such rather than as the sum of the widths of its composing characters.

The result is that FLTK text widgets now input and draw correctly also
complex emojis encoded with context-dependent codepoints, under all platforms.

This has been committed to git head and to branch-1.4 too.

Cheers,

Manolo

[Manolo]

Le mercredi 21 janvier 2026 à 16:09:33 UTC+1, Manolo a écrit :

……

For FLTK text widgets to handle correctly these challenges, I have extended
to the Windows and macOS platforms the procedure already used under X11/Wayland
by function fl_draw(const char*, int):

There's a typo here. I'm talking about function fl_width(const char*, int) (not about fl_draw)

[Greg Ercolano]

On 1/21/26 07:09, Manolo wrote:

Hi fellow developers,

[..]

some emojis are more complicated and created challenges to FLTK even though when the user selects one of them in the emoji palette nothing suggests this challenge.

One such case is for composed emojis where the desired drawn emoji is expressed in Unicode by 3 successive codepoints where the 2nd is U+200D "zero-width joiner".

[..]
Furthermore, it seems that some platforms add a 4th codepoint at the end [..] A unicode-compliant program should draw these 3 (or 4)  consecutive codepoints as a single drawable character.
[..]

Another challenge occurs with how Unicode encodes skin color.

    Wow, thanks for all your hard work on this issue -- I had no idea emojis were so complicated..!
    I figured they were just regular unicode glyphs, like fonts but with colors.

    I haven't looked at your commits, but I take it if a single emoji glyph can involve several, separate, utf8 sequences, I assume that while the OS handles font rendering, these details must impact our fl_utf8_xxx() functions so they know how to parse a "single character glyph" as multiple utf8 sequences, which must be quite tricky.

    I may have to double check my Fl_Terminal code to see if it can handle this correctly - not sure if it understands "zero width" utf8 sequences, as I think I had to make some assumptions about fixed character widths, so cursor up/down motion moves to the correct character in the lines above and below, as well as other ANSI/XTERM operations, text selection using arrow keys, etc.

[Gonzalo Garramuño]

On 1/21/2026 12:09 PM, Manolo wrote:
> Hi fellow developers,
>
> I'd like to explain here recent commits about emoji support by FLTK.
>

Thanks Manolo for the heads up.  I never imagined that asking for emojis
would be so difficult.

Now the question or request.  In order to handle emojis with multiple
Unicode code points, are you are relying on libharfbuzz for the composition?
Currently, on my Vulkan text widget, I am just handling single Unicode
code points emojis with Freetype.  You mentioned you modified fl_wdth. I
have that in place too, but is there a function in FLTK now to return
the actual composited glyph? Or do you rely on the OS functions with
libharfbuzz on Linux doing the composition?

--
ggar...@gmail.com

[Manolo]

Le mercredi 21 janvier 2026 à 20:32:20 UTC+1, ggar...@gmail.com a écrit :

Now the question or request.  In order to handle emojis with multiple
Unicode code points, are you are relying on libharfbuzz for the composition?
Currently, on my Vulkan text widget, I am just handling single Unicode
code points emojis with Freetype.  You mentioned you modified fl_wdth. I
have that in place too, but is there a function in FLTK now to return
the actual composited glyph? Or do you rely on the OS functions with
libharfbuzz on Linux doing the composition? 

FLTK under Wayland and X11 uses only pango to draw and to measure text.
Internally pango uses  libharfbuzz, but FLTK talks only to pango.

If you set a font and give pango a UTF8 string, a one line call is enough

to draw (or measure the width of) that string accounting for all complexities 

of text composition. FLTK does nothing for that. Pango takes care of

everything. For example, it does all required ligatures between arabic letters.

I strongly suggest you keep this approach.
It's exactly the same under macOS and Windows where the OS allows to 

to draw any Unicode string in any font in one call.

[Manolo]

Le mercredi 21 janvier 2026 à 19:03:30 UTC+1, er...@seriss.com a écrit :

……

    I haven't looked at your commits, but I take it if a single emoji glyph can involve several, separate, utf8 sequences, I assume that while the OS handles font rendering, these details must impact our fl_utf8_xxx() functions so they know how to parse a "single character glyph" as multiple utf8 sequences, which must be quite tricky.

In fact, FLTK has not been modifed at all regarding its UTF8-handling functions. The only change was, as explained,

to refrain from computing the width of a drawn string by summation of the widths of its unicode points.

It turns out that's enough for both FLTK text widgets to input and display correctly complex emojis.

If one accepts to type the right arrow up to 5 times to move past an emoji, moving the cursor in the text

is also correct.

In contrast, text edition with this only change is not perfect. For example, if you delete with the backspace

key a composed emoji made of 2 emojis linked by "zero-width joiner" you'll reveal the first of the 2 components.

If you type once the left arrow and then backspace, you'll delete the joiner and reveal both emoji

components. So,  yes, to support fully edition of these emoji beasts would require modifications to

the text widgets so they move or delete one composite drawable at a time.

[Albrecht Schlosser]

On 1/21/26 16:09 Manolo wrote:

Hi fellow developers,

I'd like to explain here recent commits about emoji support by FLTK.

FLTK now supports the input of emojis to FLTK text widgets using the character 

palette each OS proposes to ease the task of identifying the desired emoji.

I believe there's little doubt this is a good addition to FLTK considering
how popular emojis have become.

No doubt, and a big "thank you" from me as well.

The emoji palette opens under macOS typing cmd+ctrl+space, under Windows with
Windows_key+dot, under Linux with Windows_key+dot+space.

Unfortunately I couldn't use your recipe for Linux (Debian Bookworm) on the Gnome desktop. If I type these keys, only the keyboard language selection window opens (similar to Alt-Tab for application switch). Nothing I found on the internet (so far) worked to open a "palette" directly. The only advice that worked was to use the Gnome "Characters" application (either by hitting the Windows key and then typing "characters" until the application appears, or by running `gnome-characters` from the commandline. I attach a screenshot with several windows:

- background left, mostly hidden: `gnome-characters` window
- "Cat Face": the window I see after selecting the emoji, then I hit "Copy Character" to copy the emoji to the clipboard
- clipboard-x11: correct display of the emoji
- clipboard-wayland: looks like the hex byte values of the UTF-8 string [1]
- FLTK Editor (gray title bg): x11 backend, ctrl-v worked well to insert from the clipboard
- FLTK Editor (black title bg): wayland backend, ctrl-v inserts the same string as seen in `test/clipboard` [1]

[1] the string in the wayland editor consists of individual, editable characters:

$ od -a -t x1 emoji-wayland.txt 
0000000   \   F   0   \   9   F   \   9   0   \   B   1
         5c  46  30  5c  39  46  5c  39  30  5c  42  31

Summary: x11 backend works well, Wayland does not.

Could you take a look to fix this? Unless I'm doing something wrong.

Git master, commit:
05a3f82a5c38  2026-01-22 14:27:13 +0100 ManoloFLTK - Fix "Setting window custom cursor ..."

Many emojis correspond to single Unicode points (example: 😄). FLTK adequately
draws them in text strings and edits these strings. In contrast,
some emojis are more complicated and created challenges to FLTK even though
when the user selects one of them in the emoji palette nothing suggests
this challenge.

One such case is for composed emojis where the desired drawn emoji is expressed
in Unicode by 3 successive codepoints where the 2nd is U+200D "zero-width joiner".
Example: the "woman pilot" emoji (👩‍✈️) is encoded by U+1F469 "woman" +
U+200D "zero-width joiner" + U+2708 "airplane". Furthermore, it seems that
some platforms add a 4th codepoint at the end: U+FE0F "emoji variation selector".
A unicode-compliant program should draw these 3 (or 4)
consecutive codepoints as a single drawable character.

Another challenge occurs with how Unicode encodes skin color.
Example: the "woman with dark skin" emoji (👩🏿) is encoded by U+1F469 "woman" +
U+1F3FF "emoji modifier fitzpatrick type 6".

For FLTK text widgets to handle correctly these challenges, I have extended
to the Windows and macOS platforms the procedure already used under X11/Wayland
by function fl_draw(const char*, int):
- the width of a string containing a single unicode point is computed and
memorized in the table of character widths;
- the width of a string containing several unicode points is computed as
such rather than as the sum of the widths of its composing characters.

The result is that FLTK text widgets now input and draw correctly also
complex emojis encoded with context-dependent codepoints, under all platforms.

Thanks for the detailed explanation as well.

[Manolo]

I tried again here under Ubuntu 25.10 in a VM. 

When focus is to an FLTK text widget, typing together windows+dot+space (pressing space last) opens this

palette allowing to select one emoji category and then one emoji in it. I do that in my VM and need

the VM to capture the cursor for this to work.

This procedure is related to input methods. May be an input method

must be enabled in the first place and you don't have any in your system?

I do see that copy/paste of emojis from an FLTK app to another works OK.
It works also copying from the host machine and pasting to the VM.

But it fails from a non-FLTK app such as gnome-text-editor or gnome-terminal

although copy/paste of regular text works OK.
I'll look into this.

[Bill Spitzak]

I would check if you can copy the cat icon from the X11 fltk app to the Wayland fltk app. If that works try copying between two fltk Wayland apps.

It is possible the program with the "copy character" button is putting the wrong thing into the Wayland clipboard and this is not FLTK's fault.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/c7cc6911-af53-4284-9fb8-2dbdfb541b20%40aljus.de.

[Albrecht Schlosser]

On 1/23/26 05:09 Bill Spitzak wrote:

I would check if you can copy the cat icon from the X11 fltk app to the Wayland fltk app.

Thanks, good point. Indeed, this works.

If that works try copying between two fltk Wayland apps.

Works as well.

It is possible the program with the "copy character" button is putting the wrong thing into the Wayland clipboard and this is not FLTK's fault.

In fact it is FLTK's fault because our Wayland implementation reads the wrong mime type from the clipboard.

@Manolo: I'm attaching a quick fix that is NOT intended as a final solution, but that's how I could fix the issue for me. As you can see in the patch we're reading "text/plain" instead of "text/plain;charset=utf-8" from the clipboard.

I'll send more info (about a test tool I used to find it out) in another message. But here's a quick view of the issue (more details follow later):

 ./get_clipboard                # shell script to read X11 and Wayland clipboard contents
-----  wayland  -----
*** wl-clipboard-types = 
text/plain                      # this type is offered, but ASCII only
text/plain;charset=utf-8        # this type is what we should read (i.e. prefer)

*wl*  text/plain;charset=utf-8 =
=> 🦓                           # this is what we want

*wl*  text/plain =              # this is what we get w/o the patch
=> \F0\9F\A6\93

There are also notable differences between my current Debian Bookwork system and my Debian Trixie VM. But anyway, the patch appears to work on both systems, but it's only a demo (fixing symptoms).

BTW, on the Trixie system I can open the "emoji palette" and input emojis directly (works w/o the patch) whereas I can't open the "emoji palette" on my Bookworm system. Both systems use the Gnome desktop.

[Manolo]

> In fact it is FLTK's fault because our Wayland implementation reads the wrong mime type from the clipboard.

Yes, that's right. After a false start, commit 84b5623 should do the right thing.

[Albrecht Schlosser]

On 1/23/26 19:21 Manolo wrote:

> In fact it is FLTK's fault because our Wayland implementation reads the wrong mime type from the clipboard.

Yes, that's right. After a false start, commit 84b5623 should do the right thing.

It does in all my tests, but honestly, I don't understand what this change does. I'll try to understand this later (not today).

Thanks for the quick fix.

BTW: I'm still experimenting with combinations of executables (Gnome, other GTK apps, X11 apps) and I see many different ways to store clipboard data, particularly how UTF-8 text (e.g. emojis) are stored as, for instance, mime types STRING, text/plain, and maybe more. It's ... interesting. Not all applications use the same conventions to encode UTF-8 contents as 'text/plain' etc.. When I know more I'll likely start a new thread.

However, here's my basic script to read the clipboard contents from the commandline to analyze what can be read. There are certainly other options, but it helped me much (don't use as "good" shell programming, it's just a hack I needed):

$ cat get_clipboard 
#!/bin/bash
#

target() {
    C="`xclip -o -t $1 2>&1`"
    echo ""
    echo "*x11* $1 ="
    echo "=> '$C'"
}

get_all_targets() {
    target "TARGETS"
    target "text/plain;charset=utf-8"
    target "UTF8_STRING"
    target "text/plain"
    target "STRING"
    target "TEXT"
}

wl_get() {
    echo ""
    echo "*wl*  $1 ="
    echo "=> `wl-paste --type "$1" 2>/dev/null`"
}

wl_get_clipboard() {
    # wl_get "TARGETS"
    echo "*** wl-clipboard-types = `wl-paste -l`"
    echo ""
    wl_get "text/plain;charset=utf-8"
    wl_get "UTF8_STRING"
    wl_get "text/plain"
    wl_get "STRING"
    wl_get "TEXT"
}

echo ""
echo "-----  x11  -----"

get_all_targets

echo ""
echo "-----  wayland  -----"

wl_get_clipboard

# end of file

To use it you need to install `xclip` and `wl-paste` from Debian packages x11-apps and wl-clipboard, respectively. YMMV.

Feel free to use it as you like.

[Manolo]

>  It does in all my tests, but honestly, I don't understand what this change does. I'll try to understand this later (not today).

The change is in function data_offer_handle_offer() that runs once for each flavor of the clipboard

the OS volunteers to provide to the app. After all these runs, variable fl_selection_offer_type

should be set to the preferred flavor.

The issue is prority between flavors: we prefer UTF8 over plain text, but the function 

runs before with plain text and later with UTF8. The change allows to reset  fl_selection_offer_type

to UTF8 when it has been set before to plain text.

[Manolo]

If you uncomment line 286 of file fl_wayland_clipboard_dnd.cxx

//fprintf(stderr, "Clipboard offer=%p supports MIME type: %s\n", offer, mime_type);

any FLTK app will tell all clipboard flavors the OS volunteers to provide it.

[Albrecht Schlosser]

Thanks for the explanation, I got it now. I didn't know how the calling
sequences are ...

[Manolo]

Commit bd4ad3e is intended to complete support of composed unicode characters.

With it, both FLTK text widgets process a composed character (example: 👩‍✈️) as a

single entity when:

- moving through text with left and right arrows;

- deleting characters to the left or the right of the insertion cursor;

- selecting text by dragging the mouse over it.

To get this, 2 new UTF8-handling functions were added:

[Gonzalo Garramuño]

Thanks, Manolo.  I have a question for developers:

- Should fl_utf8toa() also handle composed characters and return a
single character?
- Maybe it should be optional?

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 1/24/26 12:33 PM, Manolo wrote:

> Commit bd4ad3e is intended to complete support of composed unicode
> characters.
> With it, both FLTK text widgets process a composed character (example:
> 👩‍✈️) as a
> single entity when:
> - moving through text with left and right arrows;

This is currently broken, just as in my Vulkan text widget.

To reproduce:

- Add a flag (Argentina in my test) and then a normal letter (say 'f').
- Move backwards left from the f to the flag.  There's a stop in an
invisible character between the flag and the 'f'.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

Tested on latest FLTK official GitHead on macOS Intel.

--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le samedi 24 janvier 2026 à 17:18:07 UTC+1, ggar...@gmail.com a écrit :

- Should fl_utf8toa() also handle composed characters and return a
single character?
- Maybe it should be optional? 

I don't uderstand at all the purpose of that function and what it does. 

[Gonzalo Garramuño]

I think it turns utf8 characters into a ASCII characters or a space when it cannot be converted (ie. not Latin1).

I believe it can be also be used to measure the length of utf8 again for as it foreign characters were just ASCII.

BTW... have not looked at the implementation.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Yes, I had missed that emoji flags are another kind of composed characters. That should be fixed

with commit 521f7b3. I have now considered all sorts of emojis and hope they are all covered

by this new commit.

[Gonzalo Garramuño]

I have not said this before, but should have.  You are awesome, dude!

--
Gonzalo Garramuño
ggar...@gmail.com

[Greg Ercolano]

On 1/24/26 14:34, Manolo wrote:

Le samedi 24 janvier 2026 à 17:18:07 UTC+1, ggar...@gmail.com a écrit :

[..] fl_utf8toa() [..]

I don't understand at all the purpose of that function and what it does. 

    Offhand and without looking, I'd a guess it turns unicode chars
    like á/à/â/ã/ä/å into just "a", useful for certain kinds of sorting,
    or in contexts where pure ASCII is required, like domain names,
    hostnames, and other pre-unicode contexts.

[Albrecht Schlosser]

Not really...

The 'a' in  fl_utf8toa() and  fl_utf8froma() likely meant 'ASCII' in the past, but actually it means ISO-8859-1 aka (ISO-)latin1.

fl_utf8froma() converts a string in the single byte encoding ISO-8859-1 to a UTF-8 string which can be longer than the source string because a character in the upper part of ISO-8859-1 (0xA0 to 0xFF) needs two bytes in UTF-8 encoding. fl_utf8toa() does the opposite, but note that it can only convert UTF-8 sequences that correspond to ISO-8859-1 characters to equivalent single bytes. All other characters are converted to '?'.

That said, these functions are probably no longer useful for FLTK (internally) and likely not for user programs as well. There is only one occurrence of fl_utf8toa() in test/utf8.cxx which can easily be removed/replaced by using UTF-8 encoding directly (I'm working on this).

IMHO these two functions should be deprecated and eventually removed (in FLTK 1.6).

[imacarthur]

On Monday, 26 January 2026 at 10:13:33 UTC Erco wrote:

    Offhand and without looking, I'd a guess it turns unicode chars

    like á/à/â/ã/ä/å into just "a", useful for certain kinds of sorting,
    or in contexts where pure ASCII is required, like domain names,
    hostnames, and other pre-unicode contexts.

It hadn't occurred to me it might do that  - and it seemed like a Good Idea if it could.

So I went and tried it, and was disappointed to find that's _not_ what it does. Pity...

Anyway, as best I can tell (and I think this aligns with what the comments say...) it basically will take a UTF8 sequence, and IF it is well-formed, and IF the resulting character maps into ISO-8859-1 ASCII (or maybe into CP1252) then it gives you back that "ASCII" character.

If it's not, then you either get one (or more) ? characters, or the "raw" UTF8 sequence handed back to you...

So... I'm not sure what I'd use that for, TBH...

[Bill Spitzak]

These functions date back to when the easiest way to see an UTF8 string was to convert it to a 1-byte string and draw that. It really did not care what it turned characters >255 into as long as they were not control characters. I agree this is probably entirely obsolete now, all the apis accept UTF-8.

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/d6b39d16-353d-431c-8902-187980192467n%40googlegroups.com.

[Manolo]

Le lundi 26 janvier 2026 à 16:17:24 UTC+1, Albrecht-S a écrit :
…

That said, these functions are probably no longer useful for FLTK (internally) and likely not for user programs as well. There is only one occurrence of fl_utf8toa() in test/utf8.cxx which can easily be removed/replaced by using UTF-8 encoding directly (I'm working on this).

IMHO these two functions should be deprecated and eventually removed (in FLTK 1.6).

I support the suggestion to deprecate these 2 extremely old-fashioned functions.

[Albrecht Schlosser]

On 1/27/26 16:47 Manolo wrote:

Le lundi 26 janvier 2026 à 16:17:24 UTC+1, Albrecht-S a écrit :
…
> That said, these functions are probably no longer useful for FLTK (internally) and likely not for user programs as well. There is only one occurrence of fl_utf8toa() in test/utf8.cxx which can easily be removed/replaced by using UTF-8 encoding directly (I'm working on this).

FTR: done in commit 38fbd41896559cbeb8b922805753c4532bd0861b.

> IMHO these two functions should be deprecated and eventually removed (in FLTK 1.6).

I support the suggestion to deprecate these 2 extremely old-fashioned functions.

+1

There are probably some more such obsolete functions, particularly:

FL/fl_draw.H:FL_EXPORT const char *fl_latin1_to_local(const char *t, int n = -1);
FL/fl_draw.H:FL_EXPORT const char *fl_local_to_latin1(const char *t, int n = -1);
FL/fl_draw.H:FL_EXPORT const char *fl_mac_roman_to_local(const char *t, int n = -1);
FL/fl_draw.H:FL_EXPORT const char *fl_local_to_mac_roman(const char *t, int n = -1);

... and likely also:

FL/fl_utf8.h:FL_EXPORT char *fl_utf8_to_locale(const char *s, int len, unsigned int codepage);
FL/fl_utf8.h:FL_EXPORT char *fl_locale_to_utf8(const char *s, int len, unsigned int codepage);

The latter two functions seem to be undocumented and Windows-only.