Have Characters that Depict Electronic Components been Discussed?

[Giacomo Catenazzi]

You are diverging the discussion.

Write once: do it in HTML: we can write and use very old pages. For such 
reason a markup language for technical design may be appropriate. On 
Unicode: it will be ugly and not so useful. Again: you see maybe no real 
usage of the technical design characters we already have in Unicode. It 
is just the wrong approach and nobody like it.

Terminals can display images (photos) and graphics since a lot of years. 
I know it, and I use seldom for harfbuzz (some helper/debugger toools in 
there). For photo: I used few times just to check capabilities. And it 
is the general experience (maybe most of people never tried it). Why? It 
may seem a good idea (so maintainers of terminals implemented it), but 
no practical usage (we do not use it). HTML views are much better and 
supports much more language, or we keep simple text only terminal with 
few features. What it is in between it is just a bad trade-off. Which it 
seems also your proposal.

With a proper markup language we can design simple diagram, and so 
telling people how an oscillator work, or an amplifier, with annotation 
for R1, R2, C1, etc. and maybe also writting the resistance in Ohm. With 
your proposal it will be ugly or impossible, and it will work only for 
few languages.

Terminals sucks on Unicode: Unicode provide single and double width 
characteristics to characters, to help terminals, but still... way far 
from real terminal display which can be useable. And Unicode should not 
implement full maths writing (it will be ugly and not user-friendly: we 
need a mark-up language), so your proposal (on terminal) would make no 
sense: putting some electronic components, but we cannot draw simple 
circuits, annotate them, and write the equations. Also terminals have 
(usually) no magnifying function), and most cannot contain too many 
"pixels" (also as default), so we need to handle paging and the rest (so 
not just plain text, but a rendering engine), and so redoing HTML but on 
a "budget" and with much more technical limitations. The worst of the 
two world.

Also terminal are not "write once". I'm using Linux since 1996 and I 
experience that. At beginning we had to try to guess the best VTxxx and 
set it. Much later "linux" was added, and "xterm", etc. And then all 
problems with colours: terminal identifier was not a precise identifiers 
of capabilities, so many programs had different idea.

Unicode entered later, and initially support was just for "ISO 10646 
Level 1" (see Unicode as "Level 3". Note: Levels are obsolete). Telnet 
also changed (assumption of characters). SSH is evolving and we cannot 
use old protocols. You listed HTTP and HTTPS as difference, but who 
cares? As content authors (which it seems the context of this proposal) 
it doesn't matter. Just the system administrator will set-up the server. 
But you need such person in any way: updated are needed: security bugs 
and other bugs needs to be corrected.

And adding your symbols: it requires a lot of works and updated of many 
components to be able to be displayed, and hoping most systems will 
install a default font for your symbols (as you see default fonts lacks 
many characters, so forget about it): HTML allows you to use "webfonts" 
which are normal fonts, but loaded on demand, and provided by server. 
And because a reference implementation could be done in Javascript, 
transforming the language into SVG, it may work without any work or 
update on user side.


You really underestimate how much work should be done in each computer 
to have terminals to display technical text, both sides (user and 
content), and not on all languages. And ugly. We may be (unfortunately) 
used on terminal and monospace fonts, but let's face it: they are ugly, 
slower to read, and if you add Greek characters (as done in electrical 
charts) into terminals, our eyes have difficulties to read quickly. Also 
colours are not standardized. Bold is inconsistent. And it requires good 
terminal client and good fonts installed on user side.


Or show us examples of what you mean, so we can test on our terminals, 
and so we may get an idea that someone will spend time to create content 
and using the extension.  Else we should just wait until we had such 
good example and then re-evaluate. For now it is not useful to continue 
discussion. Show your work!

giacomo




On 2024-08-18 22:54, Martin Vahi via Unicode wrote:
>
> First of all, thank You to everybody for their helpful answers.
> I think that I'll settle with what R.B. suggests at the next quote:
>
> On 8/17/24 11:49, Rebecca Bettencourt via Unicode wrote:
> >...
> > 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.
> >...
>
> What regards to the J.D. statement at the next quote
>
> On 8/16/24 21:56, Jim DeLaHunt via Unicode wrote:
> >...
> > 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?
> >...
>
> then, again, thank You, it's a helpful read, but my answer to the
> question about my reluctance to using those higher-level protocols is
> that from software developer's perspective I just want to WRITE ONCE
> WITHOUT NEEDING TO REWRITE OLD SOFTWARE unless the end user requirements
> for the software change. For example, in my view, if some application
> uses Adobe Flash or Java Applets or Microsoft Silverlight or VRML that
> at some point are not supported by mainstream web browsers or their
> default-installed-plugins, then from my perspective the need to swap
> out the code parts that depend on or are implemented in Java Applets
> and alike is NOT AN END USER REQUIREMENT CHANGE but just a nuisance due
> to technology trend changes. End users could not care less, if the 3D
> thing that they move with their mouse is in some Java Applet or WebGL or
> what ever else, as long as it just works for them without fiddling with
> the computer. Text based things TEND TO WORK, but those higher-level
> protocols tend to NOT BE RELIABLY AVAILABLE.
>
> An example: anything with an URL that starts with https. The moment some
> crypto algorithms change, may be some signing servers at the chain of
> domain authentication change, there is suddenly a need for those changes
> to be reflected at client computer, be it some "trusted certificates"
> or recompilation of a newer version of the openssl library (in Linux
> world).  That's not exactly a kind of technology that one can use at
> some laptop that is shipped with industrial equipment for changing
> the settings of that equipment about 10 years after the sales, unless
> there is some direct cable going from the industrial equipment to the
> laptop that was shipped with it, provided that the laptop will even
> boot after its Flash memory based SSD has lost the data over time. With
> magnetic disks there's actually hope that the computer will boot, if
> the disks have been kept cool enough. As of 2024_08 the best workaround
> that I'm aware of to the data loss problem is to ship MDisc DVD's for
> reinstalling everything from scratch or to use MDisc based "live" disks.
> With the MDisc DVDs or MDisc BluRay based solution one can use what
> ever fancy software of a given era, with the caveat that electrolytic
> capacitors on motherboards have an approximate life span of 20 years
> even in storage. According to some statements on the Wild-Wild-Web the
> new supercapacitors do not last longer than the old style electrolytic
> capacitors. Basically, the best bet from hardware point of view is to
> try to craft software so that it would work with future computers, which
> might lead one to think about the use of emulators: just install all
> in a virtual appliance and the virtual appliance will run on future
> computers.
>
> The virtual appliance based approach is, what is being tried for running
> old industrial equipment and there even seem to be virtual appliance
> running software agnostic virtual appliance storage device image formats
> like the OVF
>
>     https://www.dmtf.org/standards/ovf
>     archival copy: https://archive.ph/rZJdJ
>
> but, again, will that be the
> "new Java Applet"/"new Microsoft Silverlight"/"new Adobe Flash"?
> Virtual Appliance running software is not exactly a small piece of
> software that somebody could easily maintain oneself as a small side
> project, although with the future RISC-V CPU-s there might be hope that
> all future CPUs will support the basic RISC-V instruction set and then
> there might be a chance to write the emulators once and the core of
> them would work on all CPUs and the virtual appliance running software
> becomes maintainable to a small team of people, who maintain it as a
> small side project.
>
> If Intel and AMD intentionally avoid supporting the RISC-V instruction
> set, then that might be solved through some general emulator layer that
> Linux will have anyway, so no problem even with those megacorporations,
> unless they start making efforts to NOT run Linux, in which case they,
> Intel and AMD, would probably be eliminated from server market. On the
> other hand, Intel and AMD might not mind taking the same path business
> wise that a huge market leader named Nokia took...
>
> That is to say, as of 2024_08 I'm just too stupid to know, what to use 
> other
> than text for creating any kind of reliably future proof user interfaces.
> I guess old style HTML with images and open source "retro-browsers" like
> Dillo or RetroZilla
>
>     https://rn10950.github.io/RetroZillaWeb/
>
> might actually work too. If somebody can maintain/create/develop the
> RetroZilla web browser nowadays(2024), then there's hope that some
> analogue of it will be available in the future too. The problem,
> although relatively minor, is that there needs to be some connection
> between the "RetroZilla" and the command line application and that
> connection uses operating system API. Opening a port for HTTP is an
> operating system matter. May be future operating systems might need
> some extra fiddling to get "legacy IPv4 port support" working. On top
> of that Microsoft Windows like operating systems might just plain
> block anything that wants to open a port, a lot like Windows10 has
> those dialogues that ask for firewall hole permissions whenever a newly
> installed application wants to connect to the Wild-Wild-Web. Obviously
> Microsoft and Apple like companies could not care less, whether some
> small freelancer like me can ship software that my remote clients are
> actually able to start using without looking for some local IT-support
> guy to click the "right OK buttons". Or in the case of industrial cases,
> Microsoft and Apple will not pay for the working hours and travel costs
> of industrial equipment manufacturing technicians that need to travel
> to the other side of the globe to do some mundane setup work. At the
> same time industrial electronics manufacturers tend to provide software
> libraries and drivers only for Windows, so Linux is less of an option in
> industrial equipment that contains that industrial electronics. (Factory
> owners refuse make their factory robots remotely accessible due to a
> fear of being blackmailed by ransomware creators.)
>
> Plain text seems to stand the test of time the best, despite the awful
> pre-Unicode encodings era, where may be only the Japanese got it right
> from the very start with their Tron encoding.
>
>     http://justsolve.archiveteam.org/wiki/TRON_code
>     archival copy: https://archive.ph/KZpC8
>
> I'm just yearning for a possibility to write software once without it
> stop working due to 3rd party activity. Text based user interfaces seem
> to be the most robust ones that I'm currently, as of 2024_08, aware of.
> That explains, why I'm reluctant to use higher-level protocols.
>
> Thank You for reading my letter and
> thank You for Your answers.