<div dir="ltr"><div>How did this go from schematic symbols (something that is, however *improbable*, at least *possible* to argue for encoding) to arbitrary bitmaps (something that is never going to become part of Unicode, ever)?</div><div><br></div>Look up sixel graphics and ReGIS. Spend energy on getting terminal emulators and command line applications to support these already-existing higher-level protocols instead of trying to half-bake a new one into a text encoding standard that will never accept it.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>-- Rebecca Bettencourt</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 16, 2024 at 12:00 PM Jim DeLaHunt via Unicode <<a href="mailto:unicode@corp.unicode.org">unicode@corp.unicode.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-08-16 11:23, Martin Vahi via Unicode wrote:<br>
<br>
> … the "cloud AI" era works largely on Virtual Private Servers (VPS) or <br>
> some<br>
> analogues…, where the party that pays the rent for<br>
> the computing resources logs in (or uses scripts/bots to log in) to the<br>
> rented computing resources over SSH, which uses text based terminal user<br>
> interface. In theory one could use some X11/VNC/RDP protocol and spend<br>
> a considerable amount of the rented RAM on fancy windowing environment<br>
> that will not be used most of the time.…<br>
<br>
Or, and here is a crazy idea, one might run an HTTP server on the VPS, <br>
and have it serve HTML pages, and have the clients connect using <br>
existing web browsers, which can display the mixed graphics, text, and <br>
interactivity of the HTML pages.<br>
<br>
<br>
> …The EFFICIENT solution: command line tools!…<br>
<br>
The thing to be careful about when appealing to efficiency is the <br>
question of which costs you include in your measure of efficiency, and <br>
which costs you externalise and thus ignore. Among the costs of <br>
extending text constructs to include graphics are the cost of making <br>
fonts with more and more graphic "characters", the costs of figuring out <br>
how the make graphics out of the "characters", and the costs of text <br>
complexity for those other applications that don't need or want the <br>
graphic capability you are adding.<br>
<br>
<br>
> … all modern general<br>
> purpose programming languages support text. Many of them support Unicode<br>
> text encoding, UTF8. From software development point of view the<br>
> possibility to do graphics by just printing characters adds a really<br>
> useful capability TO ALL THOSE PROGRAMMING LANGUAGES THAT SUPPORT UTF8.<br>
<br>
All those modern languages also have support for generating HTML and <br>
implementing HTML-based applications.<br>
<br>
<br>
> In "cloud AI" era many applications are command line applications.…<br>
In a "cloud AI" era many applications are distributed systems which <br>
communicate via network-mediated interfaces. I would argue that the <br>
command line is among the less important interfaces of those <br>
applications. The network interfaces to talk to their distributed <br>
relatives are more important.<br>
> … if some SSH-accessible administration command line utility wants to<br>
> display a graph that includes a cycle, then a lot of inventiveness might<br>
> be required.…<br>
<br>
Or, the command line utility could spin up an HTTP server hosting an <br>
HTML page with an SVG illustration of the graph and its cycle, then <br>
print on stdout the URL of that page. That is a relatively low cost to <br>
implement, because there will probably be libraries available for the <br>
HTTP server, the HTML generation, and the SVG generation.<br>
<br>
<br>
> An alternative is to come up with a new character encoding scheme that<br>
> uses Unicode as a sub-set, a lot like the Unicode used ASCII as its<br>
> subset.  The new character encoding will need to have then some UTF8<br>
> analogue that uses UTF8 as its subset.  Decent mainstream terminal<br>
> programs that are meant to be used at the "cloud AI" era must then adapt<br>
> that new character encoding scheme…. The problem with this approach is<br>
> that the various programming language implementations won't adopt it<br>
> quickly, but some eventually will. An interim solution might be like<br>
> Unicode is supported in ASCII-only C++ strings: special coding.<br>
> Easier said than done, but I guess that it's theoretically possible.<br>
<br>
Or, use the alternate, text plus graphics paradigms which already <br>
support this. The Unicode design principles say that Unicode is centred <br>
on exchange of universal plain text, and it leaves a lot of domains to <br>
"higher-level protocols". Why are you so reluctant to use the <br>
higher-level protocols?<br>
<br>
<br>
-- <br>
.   --Jim DeLaHunt, <a href="mailto:jdlh@jdlh.com" target="_blank">jdlh@jdlh.com</a>     <a href="http://blog.jdlh.com/" rel="noreferrer" target="_blank">http://blog.jdlh.com/</a> (<a href="http://jdlh.com/" rel="noreferrer" target="_blank">http://jdlh.com/</a>)<br>
       multilingual websites consultant, Vancouver, B.C., Canada<br>
<br>
</blockquote></div>