Fixed Why ↔ gets converted to an emoji when used in posts?

Aivaras

Active member
I have both "Convert Markdown-style content to BB code " and "Convert short code to emoji / smilies " unchecked in ACP. When I use the left-right arrow symbol in a post, it gets converted to its emoji equivalent like so: ↔

Enclosing ↔ in [PLAIN] tags solves the problem. This is not efficient though, more of a temporary workaround. Can this character conversion be switched off globally in XF? If so where?
 

adamgreenough

Well-known member
As I understand it these are an OS/Browser level thing. Try doing the same in a plain HTML file with the utf-8 charset and I believe you’ll get the same result due to a crossover in the Unicode codes(?). Citation needed. 😋
 

Chris D

XenForo developer
Staff member
Actually, I think this is a bug in the underlying library which converts emoji characters to images.

So, this emoji 😋 gets converted to an image: 😋

As noted ↔ gets converted to an image too: ↔

It shouldn't, it isn't really an emoji.

I believe this is fixed in a later version of the library, but the changes within it are quite extensive which may make it difficult for us to implement in 2.1.x, but we'll look into it.
 

adamgreenough

Well-known member
Actually, I think this is a bug in the underlying library which converts emoji characters to images.

So, this emoji 😋 gets converted to an image: 😋

As noted ↔ gets converted to an image too: ↔

It shouldn't, it isn't really an emoji.

I believe this is fixed in a later version of the library, but the changes within it are quite extensive which may make it difficult for us to implement in 2.1.x, but we'll look into it.
Did some experimenting. Seems to be a font thing.


I see emoji in Verdana but not in Arial on iOS. What about you?
 

Chris D

XenForo developer
Staff member
That isn't the issue here. It's as I've described.

I may have a solution but not currently certain what impact it will have on emoji conversion generally.
 

adamgreenough

Well-known member
That isn't the issue here. It's as I've described.

I may have a solution but not currently certain what impact it will have on emoji conversion generally.
OP says emoji image conversions are off. Is OP seeing the emoji image (from XenForo) which would be a bug or the OS emoji character (seemingly a font quirk).
 

Chris D

XenForo developer
Staff member
OP says emoji image conversions are off. Is OP seeing the emoji image (from XenForo) which would be a bug or the OS emoji character (seemingly a font quirk).
He has short code to image conversions off, e.g. :slight_smile: being converted to 🙂

That's different to converting 🙂 to 🙂

For the avoidance of doubt, I have already categorically confirmed the issue exists in our code so other quirks that exist on some platforms aren't currently suspected as being related.
 

adamgreenough

Well-known member
He has short code to image conversions off, e.g. :slight_smile: being converted to 🙂

That's different to converting 🙂 to 🙂

For the avoidance of doubt, I have already categorically confirmed the issue exists in our code so other quirks that exist on some platforms aren't currently suspected as being related.
Ah gotcha. 👍 Sorry, I had similar issue in past and it turned out to be font related so just wanted to throw it out there. 😄
 

XF Bug Bot

XenForo bug fixer bot
Staff member
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.1.6).

Change log:
Revert a previous change related to the conversion of some non-emoji characters to images.
There may be a delay before changes are rolled out to the XenForo Community.
 

Aivaras

Active member
Has this been noted by the developers? Just making sure it is not getting lost as "fixed."

Another question: can some suggest a temporary workaround? Using [PLAIN] tags does not work.
 

Chris D

XenForo developer
Staff member
I’ll move back to bugs but there may be some relevant changes coming to 2.2 so the fix may be there.

You can see from your previous post that PLAIN tags do work.
 

Chris D

XenForo developer
Staff member
You can see here that it does:

EFCCB5AE-D5AE-4A2A-B84A-D5D63E67CF33.jpeg

The blue one is what we’re responsible for - we’re detecting it as an emoji and replacing it with a JoyPixels image.

The grey one is just how iOS chooses to render it in the font they use. We have no control over that.

I know you’re expecting it to look like a plain ASCII character in all cases but iOS is responsible for it not being due to the font it uses.

We’ll only be able to try to address the change into the blue image.
 

Aivaras

Active member
Thank you for the explanation! The BB code band aid still does not work for us. Too much textual terrain to cover. And it does not work in such cases as thread titles. You seem to have fixed it on this board now, right? Because yesterday the title of this thread had the double arrow symbol converted to its emoji equivalent.

We'll have to wait patiently for the release of the fix proper. It's an important one for us as it interferes drastically with post typography.
 

Chris D

XenForo developer
Staff member
No changes have been made here.

Again, it depends on the font in use by the browser.

I know it should look like this (Chrome):

1592657792223.png

But it will always look like this in iOS unless they make a change:

1592657835023.png
 

Aivaras

Active member
Hm..., my memory is then failing me. I thought I was checking it on Firefox desktop and seeing the tile with the emoji. Yesterday, that is…
I know you’re expecting it to look like a plain ASCII character in all cases […]
Yes, it's an operator sign widely used in some types of literature.
 

Chris D

XenForo developer
Staff member
The regression was actually caused by the changes we made due to this bug report:

There were situations where certain emoji like ⚠ would get converted to unexpectedly.

The fix for that started converting ↔ to ↔.

I am in the process of making some changes in XF 2.2 with a new version of the JoyPixels library and it seems to be resolved in their code so I think we can revert that original change.

With that in mind, this is fixed, but not until XF 2.2.0, but that shouldn't be too long away...
 
Top