The conflicting needs of emoji
wjgo_10009 at btinternet.com
Sat Oct 15 10:22:53 CDT 2022
Mark E. Shoulson wrote:
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.
Saturday 15 October 2022
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unicode