Unicode Characters Showing as Emojis

English
#1

I have an .odt doc which uses the the Black Right-Pointing triangle character (See https://www.compart.com/en/unicode/U+25B6 for an example.)

However, on Linux Mint 21, LibreOffice renders it as a Play Button emoji (see https://emojiterra.com/play-button/ for an example.)

On the latest version of Xubuntu and Windows 11, the doc renders it as a Unicode triangle. Only on Linux Mint does it show as an emoji. All three OSes are on the same version of LibreOffice.

Linux Mint renders the Unicode triangle correctly elsewhere (Text Editor, web browsers, etc.) Only in LibreOffice (I’ve tried both Writer and Impress) does it show as an emoji.

Even more problematic: when I export the doc as a .pdf, it saves it as a Unicode arrow, but it’s transparent (or perhaps white). You can’t see if, but you can select it and paste it into another doc to confirm it’s the Unicode arrow.

Is there a setting where I can turn off converting Unicode characters to emoji?

Thanks for any help you can give. I’ve spent a couple hours on this and haven’t found a solution yet.

#2

Cross-posted at https://old.reddit.com/r/libreoffice/comments/wmlt0u/special_unicode_characters_showing_as_emojis/.

1 Like
#3

We know you’re under Mint but which release? What is your LO version?
For best diagnostic, attach a sample file with your “right-pointing triangle”. Which font is used to display it?

#4

The play button is the U+25B6 U+FE0F sequence, where the U+FE0F Variation Selector-16 exactly distinguishes the emoji from the plain text character. If Mint displays U+25B6 alone as play button it does it wrong. Or do you by chance have a play button in the document and it’s not displayed correctly on Xubuntu and Windows?

#5

Version of LibreOffice: 7.3.5.2 (same on Windows 11, Linux Mint 21, Xubuntu 22.04)

I’ve attached an document with the arrow in it. In LibreOffice, it shows as an emoji. If I select the character and paste it anywhere else on Linux Mint (Chrome’s URL bar, Text Editor, etc.), it shows as the Unicode character.

If I change the font to certain fonts, it renders as a Unicode shape, such as DejaVu Sans. But in Calibri, which is what the rest of the document is in, it renders as an emoji. Again, this only happens in LibreOffice in Linux Mint.

My current workaround to export it to PDF successfully is to log in to a Xubuntu virtual machine, which renders the document as intended.

I thought it might have something to so with fallback fonts. I found this article…

http://eosrei.net/articles/2016/02/changing-default-fallback-subsitution-fonts-linux

and followed it’s instructions, but the problem remains.

Below, I’ve attached a sample .odt. Since I’m a new user, I can’t attach multiple files, so I’ll add them in a second and third post.

Thanks for your help!

Arrow.odt (8.8 KB)

#6

Here’s how LibreOffice in Mint renders it.
Emoji in LibreOffice

#7

And here’s how it renders when I copy the “emoji” from LibreOffice and paste it anywhere else in Mint (in this case, the URL bar for Chrome).

Unicode in Chrome URL bar

#8

It happens the same in Fedora Linux 36, LO 7.3.4.2, irrespective of the font face. I suspect some AutoCorrect behind the scene but couldn’t find any setting to disable it. Hard-wired in the code? In this case this is a design error unless it is an artefact in the font renderer.

If you accept to use a slightly different glyph, i.e. U+25BA BLACK RIGHT-POINTING POINTER instead of U+25B6 BLACK RIGHT-POINTING TRIANGLE, you can insert it in one of two ways:

  • type U+25ba followed by Alt+x
  • with AutoCorrect enabled, type //> (but doesn’t seem to be included in the English (USA) list)


EDIT
According to this Wikipedia article, the Geometric Shapes block contains eight emoji. Selection between base shape and emoji is controlled by an additional suffix “function” code point, a variation selector which is a combining character: U+FE0E (VS15 for text) or U+FE0F (VS16 for emoji).

Unfortunately, it looks like Writer or its font renderer HarfBuzz ignore variation selectors.

Bug filed as tdf#150398

2 Likes
#9

Thanks for looking into this! All this Unicode/Emoji/Variation Selector is way above my pay grade!

Like the character you provided, I found a couple other Unicode arrows that don’t get turned into emojis, including ➤ and ▷. Not sure which I’ll end up going with, as nothing can be as glorious as the original :arrow_forward: . :grinning:

#10

And it is the same what fileformat shows for U+25B6. I assume that the emoji just uses this glyph, and it’s how some font has it (see “Emoji “arrow_forward” is BLACK RIGHT-POINTING TRIANGLE (U+25B6) Unicode codepoint”). And your substitution choses that font on Writer.

#11

It shouldn’t, though apparently some fonts/rendering think it would. As said,

1 Like
#12

Anyluck resolving this?
I too wish to use a black right point triangle not the play media symbol. I’m trying to represent an electric diode symbol.

#13

@risedu You can draw one in Draw and add it to a new folder Gallery so it is available in Writer. To add, group the objects then click and hold on the group for one second then drag it into the new folder in gallery. Right click it and select Title to name it.
After adding it, you can modify it to create another variant which makes it fast to create library of diodes that are all reusable.

ElectronicSymbolsInGallery
ElectronicSymbolsInGallery749Ă—425 10 KB

#14

It’s unclear what you do to insert that triangle. But looking at the “Arrow.odt” from #5 from @andydoane, I believe that the problem - at least there - is not specifying the font for the character explicitly. That file has ODF markup like

<text:p text:style-name="P1">â–¶ </text:p>

(I hope that it would show “correctly” as UTF-8 shown as Windows-1252; the actual bytes there are E2 96 B6). The important part here is the (auto)style, which is defined as

<style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard">
  <style:text-properties officeooo:rsid="00129873" officeooo:paragraph-rsid="00129873"/>
</style:style>

and which doesn’t itself define any formatting, but refers to Standard:

<style:style style:name="Standard" style:family="paragraph" style:class="text"/>

… and finally, the default paragraph style is

<style:default-style style:family="paragraph">
  <style:paragraph-properties fo:orphans="2" fo:widows="2" fo:hyphenation-ladder-count="no-limit" style:text-autospace="ideograph-alpha" style:punctuation-wrap="hanging" style:line-break="strict" style:tab-stop-distance="0.4925in" style:writing-mode="page"/>
  <style:text-properties style:use-window-font-color="true" loext:opacity="0%" style:font-name="Liberation Serif" fo:font-size="12pt" fo:language="en" fo:country="US" style:letter-kerning="true" style:font-name-asian="Noto Serif CJK SC" style:font-size-asian="10.5pt" style:language-asian="zh" style:country-asian="CN" style:font-name-complex="Lohit Devanagari1" style:font-size-complex="12pt" style:language-complex="hi" style:country-complex="IN" fo:hyphenate="false" fo:hyphenation-remain-char-count="2" fo:hyphenation-push-char-count="2" loext:hyphenation-no-caps="false"/>
</style:default-style>

All in all, it tells to use Liberation Serif; but that font doesn’t include the necessary glyph - so a font fallback mechanism triggers. And that necessarily depends on installed fonts - so naturally is system-specific. On one system, it may choose, say, OpenSymbol (which has the glyph, with the wanted shape); and on another, some different font with the glyph (where it’s colored) may get selected.

If you inserted the glyph using our Insert → Special Character, it would specify the font explicitly (which some consider problematic - see tdf#139359; but which is obviously wanted in cases like this); but if you used Alt+X Unicode insertion; or if you copied the symbol somewhere, and paster as plain text - those methods of course have no associated font information.

In general: my proposed solution would be - use Insert → Special Character, and choose OpenSymbol for the BLACK RIGHT-POINTING TRIANGLE.

#15

Just a note about my proposal of direct formatting, as opposed to a style-based approach. Of course, when you know what glyphs you need, and know a font that has them - it’s much better to use a character style. But for a case where you just happen to insert a character, ad hoc, and you don’t know what has it: the proposed “Special Character” dialog is a nice tool.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.