Texport cp1252 vs UTF8

General TouchDesigner Discussion
,
1

Hi all,

I’ve recently tried to implement “emojis” or “symbols” in my debug statements to simplify the understanding of textport at a glance, and after a while of trial and error I decided to abandon the task and resort to safer ways of achieving this (on windows, using [i], [+] and ).

However, whilst trying to make it happen, I discovered a few things that I thought might be useful to share and ask for clarification.

  1. macOS and Windows versions of touchdesigner, use different sys.stdout.encoding. Windows defaults to cp1252, macOS defaults to utf8. Is there a reason this is the case?
  2. Windows can be forced into utf8 (see this post) but every new thread will be spun using cp1252. For example, you can force utf8 in your script, but if you use one of touchdesigner’s many callback blocks (in my case, the socketIO one) any code run from that callback will be run in a separate thread (maybe) that defaults to cp1252.
  3. Even if you successfully force windows into utf8, the “on startup” scripts will ignore this setting.
  4. macOS defaults to UTF8 but can’t show emojis, it just shows a blank character. If this character is copy-pasted elsewhere, the emoji appears.

This might be me being a noob, but would it be possible to set the encoding of the textport from TD’s settings, in order for them to affect the scripts globally? Just thinking out loud really.

4

Sorry for the slow response.

I think this might be resolved now in the new 2025 release. When I test it on my Windows machine I now get the encoding as utf8 without making any changes. Let us know if you’re still having problems with it.

As far as #4, this should be fixed in our next update. Previously our font engine did not have support for colored emojis and the standard mac emoji font does not have monochrome fallback characters like windows, which meant many emojis would appear blank on macs. In the next update both windows and mac should have full colored emojis in the textport.

1 Like
6

Hi @robmc , I just tested with version 2025.32280, and the behaviour is “sorta” better, but not fixed. FYI: I’m working almost entirely with extensions.

At project startup, the emojis work. However, as soon as the startup phase has ended, I put my project into “listen” mode for socketIO messages. For this, I use the socketIO component and the socketIO callback. When I receive a message, I use the callback to jump back into my extensions by doing:

def onReceiveEvent(dat, rowIndex, message, event):
    op.COM.SanitiseEvent(event, message)
    return

As soon as this callback gets run, emojis stop rendering.

7

Hi @NiccoG

If you just add a print and comment op.COM.SanitiseEvent(event, message), do you see the emotes rendering in the textport?

If it does work, can you please share the code behind SanitiseEvent?

Thanks.

8

Hi @JetXS , below an overview of the code and a view of the textport out.

The socketIO callback:

def onReceiveEvent(dat, rowIndex, message, event):
    op.COM.SanitiseEvent(event, message)
    return

Calls the SanitiseEvent method inside “ComExt” extension:

def SanitiseEvent(self, event: str, data: Dict[str, Any]):
	"""
	Santise and parse incoming events with validation
	"""
	debug("ℹ️")
	print("😂")

and the output on the textport is:

ℹ️ 
  (Debug - DAT:/projectManager/COM/ComExt fn:SanitiseEvent line:103 time:09:22:53)
😂
9

Thanks for the details. I can reproduce some similar issues on my end and am looking into it now.

It appears that when the python goes through the callback it loses the encoding, whereas if you type directly into the console or run a dat as a script it works ok.

10

This should be fixed now in our next official update. There was a spot specifically in our callback system where any output generated during that callback would lose its utf8 encoding. This could happen in any node that uses callbacks.

Thanks again for the report and let us know if you have any more issues.

11

Happy to lend a hand, thanks for your hard work!