Have Characters that Depict Electronic Components been Discussed?

[Rebecca Bettencourt]

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)?

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.

-- Rebecca Bettencourt


On Fri, Aug 16, 2024 at 12:00 PM Jim DeLaHunt via Unicode <
unicode at corp.unicode.org> wrote:

> On 2024-08-16 11:23, Martin Vahi via Unicode wrote:
>
> > … the "cloud AI" era works largely on Virtual Private Servers (VPS) or
> > some
> > analogues…, where the party that pays the rent for
> > the computing resources logs in (or uses scripts/bots to log in) to the
> > rented computing resources over SSH, which uses text based terminal user
> > interface. In theory one could use some X11/VNC/RDP protocol and spend
> > a considerable amount of the rented RAM on fancy windowing environment
> > that will not be used most of the time.…
>
> Or, and here is a crazy idea, one might run an HTTP server on the VPS,
> and have it serve HTML pages, and have the clients connect using
> existing web browsers, which can display the mixed graphics, text, and
> interactivity of the HTML pages.
>
>
> > …The EFFICIENT solution: command line tools!…
>
> The thing to be careful about when appealing to efficiency is the
> question of which costs you include in your measure of efficiency, and
> which costs you externalise and thus ignore. Among the costs of
> extending text constructs to include graphics are the cost of making
> fonts with more and more graphic "characters", the costs of figuring out
> how the make graphics out of the "characters", and the costs of text
> complexity for those other applications that don't need or want the
> graphic capability you are adding.
>
>
> > … all modern general
> > purpose programming languages support text. Many of them support Unicode
> > text encoding, UTF8. From software development point of view the
> > possibility to do graphics by just printing characters adds a really
> > useful capability TO ALL THOSE PROGRAMMING LANGUAGES THAT SUPPORT UTF8.
>
> All those modern languages also have support for generating HTML and
> implementing HTML-based applications.
>
>
> > In "cloud AI" era many applications are command line applications.…
> In a "cloud AI" era many applications are distributed systems which
> communicate via network-mediated interfaces. I would argue that the
> command line is among the less important interfaces of those
> applications. The network interfaces to talk to their distributed
> relatives are more important.
> > … if some SSH-accessible administration command line utility wants to
> > display a graph that includes a cycle, then a lot of inventiveness might
> > be required.…
>
> Or, the command line utility could spin up an HTTP server hosting an
> HTML page with an SVG illustration of the graph and its cycle, then
> print on stdout the URL of that page. That is a relatively low cost to
> implement, because there will probably be libraries available for the
> HTTP server, the HTML generation, and the SVG generation.
>
>
> > An alternative is to come up with a new character encoding scheme that
> > uses Unicode as a sub-set, a lot like the Unicode used ASCII as its
> > subset.  The new character encoding will need to have then some UTF8
> > analogue that uses UTF8 as its subset.  Decent mainstream terminal
> > programs that are meant to be used at the "cloud AI" era must then adapt
> > that new character encoding scheme…. The problem with this approach is
> > that the various programming language implementations won't adopt it
> > quickly, but some eventually will. An interim solution might be like
> > Unicode is supported in ASCII-only C++ strings: special coding.
> > Easier said than done, but I guess that it's theoretically possible.
>
> Or, use the alternate, text plus graphics paradigms which already
> support this. The Unicode design principles say that Unicode is centred
> on exchange of universal plain text, and it leaves a lot of domains to
> "higher-level protocols". Why are you so reluctant to use the
> higher-level protocols?
>
>
> --
> .   --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (
> http://jdlh.com/)
>        multilingual websites consultant, Vancouver, B.C., Canada
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240817/b504d4d0/attachment.htm>