Aw: Re: The conflicting needs of emoji

[Marius Spix]

What is the need for your 1456 middleware system when there is already software like HarfBuzz doing exactly the same thing?

> Gesendet: Samstag, den 15.10.2022 um 17:22 Uhr
> Von: "William_J_G Overington via Unicode" <unicode at corp.unicode.org>
> An: unicode at corp.unicode.org
> Betreff: Re: The conflicting needs of emoji
>
>
> Mark E. Shoulson wrote:
>
>
> > Thoughts?
>
> A way to solve this would, in my opinion, be to produce a system based
> on the following.
>
> http://www.users.globalnet.co.uk/~ngo/14560000.htm
>
>
> 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
> system.
>
> 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
> possible.
>
> 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
>