The conflicting needs of emoji

William_J_G Overington wjgo_10009 at
Sat Oct 15 10:22:53 CDT 2022

Mark E. Shoulson wrote:

> Thoughts?

A way to solve this would, in my opinion, be to produce a system based 
on the following.

yet redesigned and updated for use with a Unicode text stream as input 
and so that as well as data types such as Integer, Boolean, Complex and 
Quaternions et cetera used then that there would also be data types of 
Point, Contour, Glyph. There could also be preset shapes for eyes, 
mouths, and so on built into the middleware and accessible by software 
methods in the middleware and those software methods callable in a 
straightforward manner from the "plain text" stream.

Then software methods to scale and move glyphs would be included in the 
1456 middleware virtual machine software running in the rendering 

That way the message sent as "plain text" would often, even usually, 
include calls with data parameters to preset software routines in the 
1456 middleware virtual machine running in the renderer but the "plain 
text" message would also be capable of containing direct software for 
the 1456 middleware virtual machine where that were needed to go beyond 
what the preset methods could do.

The 1456 virtual machine would be properly sandboxed so as to ensure 
that any risk of a virus threat getting into the host computer is not 

For the avoidance of doubt I emphasise that the accumulator register of 
the 1456 virtual machine is a sandboxed software construct and is not 
the accumulator register of the host computer upon which the virtual 
machine is running.

I appreciate that such a 1456 style system cannot become part of a 
future version of Unicode if "plain text" is required to not become 
redefined to some extent to allow such a 1456 style system to become 
included in Unicode.

William Overington

Saturday 15 October 2022

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list