Suggestion for Improving the "Insert Special Character" Feature

[KevinH]

There are in fact open source svg library sets that include all emojis. According to a websearch:

Popular Open-Source Emoji SVG Libraries

OpenMoji: 
An open-source project designed specifically for designers and developers, offering over 4,000 standardized vector emojis under a Creative Commons license.

Twemoji (Twitter/X): 
Twitter's open-source emoji graphics are widely available as standalone SVG files and packages.

Google Noto Emoji: 
Google's extensive emoji library provides vector paths supporting the entire Unicode standard.

Microsoft Fluent Emoji: 
A 3D/flat open-source collection from Microsoft available in vector formats.

svgmoji: 
A utility and wrapper library that tracks major open-source emoji sets and bundles them as scalable SVG sprites.

Iconbuddy: 
A massive free icon aggregator that indexes thousands of open-source SVG emojis from Noto, OpenMoji, and Fluent.

Given how few e-readers support emojis that use multiple codepoints, using one of these svg scalable images would be the way I would include them for general accessibility.

Calling images text, was a mistake by the Unicode standard in my opinion.
It is like in the old days when zapf dingbats used glyphs to create images.

[un_pogaz]

Okay, understandable. I just wanted to raise the point to clear it out.

And your right, as soon as you start using non-standard characters, reader support becomes unreliable, especialy for emoji on which is it better to use SVG images inded.

However, I would like to point out that emojis/images text did not just appear out of nowhere. Beyond a historical context surrounding japanese early-emojis, their main goal lies in the fact that they are, essentially, internationally standardized emoticons (ask a Japanese person how to make a happy face emoticon, not sure if you'll recognize it). Plus, text emoticons are very limited and can became too complexe to write, hence the advantage of using an image.

So I’m willing to concede that there are a lot of emojis, and that it probably would have been better to create a parallel, complementary standard rather than "forcing" them in the standard in as is currently the case, but like many things with Unicode, the current implementation is due to historical compatibility reasons and convenience for a large scale usage on raw text level.

But I became out-of-topic.

[KevinH]

The tweaks to SelectCharacter.cpp to support them are very minor. I will test to see just how doable it is on my Linux box. I would personally still use the svg emoji to standardize its appearance alone.

[KevinH]

For example with the attached patch and changes to special_chars.xml you can work with multiple codepoint emojis (at least on my up-to-date KDE Plasma Manjaro Linux box).

<chargroup label="Emojis">
<cp hex="1F1E6 1F1F6" label="" desc="antartica flag"/>
<cp hex="1F3F3 FE0F 200D 1F308" label="" desc="rainbow flag"/>
</chargroup>

diff --git a/src/Dialogs/SelectCharacter.cpp b/src/Dialogs/SelectCharacter.cpp
index 762472dc8..3b0b5bb73 100644
--- a/src/Dialogs/SelectCharacter.cpp
+++ b/src/Dialogs/SelectCharacter.cpp
@@ -124,11 +124,17 @@ void SelectCharacter::SetList()
                         QString hexcd = xml_reader.attributes().value("", "hex").toString();
                         QString label = xml_reader.attributes().value("", "label").toString();
                         QString desc = xml_reader.attributes().value("", "desc").toString();
-                        bool ok = false;
-                        char32_t codepoint = (char32_t) hexcd.toUInt(&ok, 16);
-                        if (!ok) continue;
-                        QString sval = QString::fromUcs4(&codepoint, 1);
-                        QString entity = "&#x" + hexcd + ";";
+                        // handle the case of a space delimted hex string for multiple codepoints such as emojis
+                        QStringList cplist = hexcd.split(' ', Qt::SkipEmptyParts);
+                        QString sval;
+                        QString entity;
+                        foreach(QString cph, cplist) {
+                            bool ok = false;
+                            char32_t codepoint = (char32_t) cph.toUInt(&ok, 16);
+                            if (!ok) continue;
+                            sval += QString::fromUcs4(&codepoint, 1);
+                            entity += "&#x" + cph + ";";
+                        }
                         custom_characters << sval << label << entity << desc;
                     }
                 }

And it appears to work just fine and does not mess with normal cp tags with only one hexcd.

So this would be a very very easy change to push now if people are interested.

[KevinH]

I am pretty sure all modern webkit/webengine based e-readers that are used for epub3 readers should handle this, but not sure if any of the dedicated e-reading hardware devices would. As far as I know based on a web search no Kindle hardware device would handle this. Nor would the latest Kobo e-reading hardware devices.

So this capability is probably a moot point.

[KevinH]

Originally Posted by BeckyEbook

I just released the SpecialCharacterConfig plugin for early adopters.

All I can say is wow! Very very nice. I tested moving, adding, and removing and all worked just fine!

Excellent job!

Thank you!

[DNSB]

To simplify keeping my test builds links up to date, you can find the latest test build for Windows in the Downloading Sigil test builds for Windows thread.

This build included the multi-character entries in the special characters file.

In my testing under Windows 11, the Antartica flag does not move from AQ to the system replacement but the rainbow flag does.