<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>[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?]]<br>
</p>
<p>Hello Michael,</p>
<p>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.</p>
<p>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).</p>
<p>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).<br>
</p>
<p><br>
</p>
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...).
<p>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).</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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?<br>
</p>
<p><br>
</p>
<p>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").<br>
</p>
<p><br>
</p>
<p>giacomo<br>
</p>
<p><br>
</p>
<p>[And I keep (just) the original mail, because it is not yet
passed Unicode list filters]<br>
</p>
<p><br>
</p>
<p></p>
<div class="moz-cite-prefix">On 2024-08-20 6:37, Michael De Roover
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3FEF281D-0781-463A-B298-151CB27A8F89@nixmagic.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<blockquote type="cite">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.</blockquote>
</div>
<div><br>
</div>
<div>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 <i>maybe</i>
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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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!</div>
<br>
<div dir="ltr">Met vriendelijke groet,
<div>Michael De Roover</div>
<div><br>
</div>
<div>Mail: <a class="moz-txt-link-abbreviated" href="mailto:unicode@nixmagic.com">unicode@nixmagic.com</a> (on list)</div>
<div><span style="background-color: rgba(255, 255, 255, 0);">Web:
michael.de.roover.eu.org</span></div>
<div><span style="background-color: rgba(255, 255, 255, 0);"><br>
</span></div>
<div>Mail: <a class="moz-txt-link-abbreviated" href="mailto:michaelderoover@gmail.com">michaelderoover@gmail.com</a></div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On 19 Aug 2024, at 09:19, Giacomo
Catenazzi via Unicode <a class="moz-txt-link-rfc2396E" href="mailto:unicode@corp.unicode.org"><unicode@corp.unicode.org></a> wrote:</blockquote>
</div>
</blockquote>
(...)<br>
<br>
</body>
</html>