Have Characters that Depict Electronic Components been Discussed?

Tue Aug 20 02:31:35 CDT 2024

[I was writing it privately, but because original email didn't pass the 
maillist filters I decided to write to all of you [did you use correct 
 From address?]]

Hello Michael,

Yes, we do things differently, but we do them first, and we discuss and 
change. Not the way around. I want to see a good use of it, and check if 
the selected layer is the best way to implement it (I douby). Writing 
email is cheap. And we do not need to be programmers: look the history 
of many very useful programs: done by non-programmers (working in other 
fields) with a specific need.

I see the point of the proposal, but I really think it will not used. 
And one of my point it is that the proposal suck because it is very 
limited on capability, but also not compatible with existing tools and 
terminals. The proposal will not solve the problem (limited size, 
alignment, simple and complex circuits, annotation, inadequate to write 
maths for that symbol, huge language issues), and bitmap can be already 
drawn in terminals, also on old terminals, so either one go down with 
CSI (escape sequences of terminal), or up to HTML and SVG (where we can 
animate current flow, to help understanding AC circuits).

We are just proposing like the images in terminals: a nice feature on 
paper and many people was thinking it will be used. But no: not enough 
good to replace HTML, but complex so not implemented in simple terminal 
GUI (or CLI). And so? Now it is difficult to create new terminals 
because of bloats, so we cannot do something lightweight, or something 
which can be used on other contexts (or inside an app).

Upper layers are much better: one can choose what to implement, and if 
it is done in a good way, it could be backward compatible vew decades 
(JavaScript library, or small bitmap together with vector 
implementation, or...).

As I iterated, Unicode supports a lot of technical design symbols and 
figures, but implementation sucks (default font of operating system). In 
a terminal how do you solve it? If we cannot do thing that are defined 
long time ago, why do you think new block will solve the problem 
(without having a good compelling example, so people can test and force 
to have a good implementation).

In any case, telnet cannot be used anymore. ssh changed (same problem 
with algorithms as TLS: unable to access old machine, or the inverse). 
Terminal behaviour is not well defined (see colours). But both are 
different layers, like TLS. We can port CERN html and view in modern 
browser (luckly they prefered explicit escape of accented characterd), 
no need to look of the different layer. Note now we write HTML with 
UTF-8 (so Unicode), but HTML is not linked to Unicode: we add freedom. 
And updating layers (like TLS) is not difficult: changing semanting is 
bad. But TLS doesn't change that. And a Raspberry Pi can do a proxy 
webserver (which were supported since long time), so you can use a 
non-TLS webbrowser on modern web (but new HTML, Javascript, CSS, etc.). 
You can do automatically.  This proposal (terminals) cannot do it. You 
cannot reformat pages (e.g. for new languages) automatically, but if you 
arelady wrote them in an higher layer. So just do this proposal in an 
upper layer, and convert to SVG for terminals: you have all advantages.

This proposal will make more incompatible old terminals. Or tell me how 
do you support the proposal in terminals. Do we need a complete new 
interface to select a font for each Unicode block? How to add a font 
which support this proposal?Do you think terminals will magically 
support Unicode blocks just because they are listed in a obscure page in 
Unicode Standard?

We cannot implement it in a good way. Noway. (a upper layer is much 
better). And we are ignoring most of the world again (terminal are 
enough good for English, going on other language the suckisness 
increase, until "non-useability").

giacomo

[And I keep (just) the original mail, because it is not yet passed 
Unicode list filters]

On 2024-08-20 6:37, Michael De Roover wrote:
>> 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.
>
> I think this is actually a nice approach for Martin to look into 
> further. He's probably right in that TLS is "an enemy" in very old web 
> browsers, albeit not expressed all that well IMO. Going by personal 
> experience with an old PSP of mine, its CA certificate store is way 
> out of date. Nothing except /maybe/ Google (haven't tried, perhaps I 
> should've) is going to be accepted by its web browser if it uses TLS. 
> Usually I see people working around that by either using TheOldNet, or 
> a forward proxy that terminates TLS. I only use reverse TLS 
> terminating proxies myself, but NGINX does that for me and I have no 
> reason to doubt it being able to do that in forward mode as well.
>
> Granted, even after overcoming the TLS hurdle, rendering would be 
> next. These old web browsers are a nightmare when it comes to their 
> HTML rendering capabilities. My own website has a local counterpart 
> (web.lan), which does not use TLS. Just like my public website, it 
> uses no JavaScript but has a persistent bar at the bottom. The PSP's 
> web browser cannot render that bar correctly (bar is rendered at the 
> bottom of the document, not fixed), otherwise it was all fine. 
> Combined text and images meanwhile should be no problem, even for 
> earlier browsers still. The only concern I'd have with e.g. early 
> 2000s flip phones, is that they may run out of memory with high 
> resolution images. They may also not support all image formats, 
> especially PNG or WEBP. My first choice for that would likely be BMP, 
> if the format and viewers support monochrome and resolution is 
> sufficiently low. Being uncompressed, output size should be easy to 
> calculate in advance, and easy to render by a flip phone's 
> microcontroller.
>
> Either way, in retro applications, it's important to target the lowest 
> common denominator. Granted, Martin's questions do not strike me as a 
> retro computing subject — rather one of terminal emulators' (or even 
> plain TTYs') rendering capabilities. So perhaps focus should be given 
> to CLI web browsers like elinks, lynx, w3m, ... instead. I think that 
> some of those can display images, by inline converting them into sixel 
> graphics. From what I've seen on Wikipedia about sixel graphics, it 
> even seems quite close to the block character proposal mentioned by 
> Martin before. The only appreciable difference to me is that it's 
> 1x6px for each character instead. And if that doesn't cut it either, 
> perhaps implementing it in the terminal emulator using the private-use 
> space in Unicode could be an option instead? Wouldn't be the first 
> time that the Linux community does things "our own way", and it 
> certainly wouldn't be the last either. At least with private-use, it 
> would not cross into Unicode's public space, and perhaps provide a 
> (more) compelling case for inclusion in the future. Still a long shot, 
> but at least better than it is now I guess.
>
> N.B.: Along with an email I sent to Martin and the mailing list 
> yesterday, this appears to be my first submission to the list. Could 
> one of the list moderators please look into what may be my account 
> still being on moderation? Thank you!
>
> Met vriendelijke groet,
> Michael De Roover
>
> Mail: unicode at nixmagic.com (on list)
> Web: michael.de.roover.eu.org
>
> Mail: michaelderoover at gmail.com
>
>> On 19 Aug 2024, at 09:19, Giacomo Catenazzi via Unicode 
>> <unicode at corp.unicode.org> wrote:
(...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240820/02cd895b/attachment-0001.htm>