## Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

One of the earliest ‘inventions’ on the Internet, were ‘Smilies’, which were just typed in to emails, and which, when viewed as text, evoked the perception of whichever face they represented. But, graphical user interfaces – GUIs – replaced simple text even in the 1990s, and the first, natural thing which developers coded-in to email clients was, the ability to convert typed, text-based smilies, into actual images, flowed with the text. Also, simple colon-parenthesis sequences were replaced with other, more varied sequences, which could be converted by some email clients into fancier images, than simply, smiling faces.

Actually, the evolution of the early Internet was slightly more complex than that, and I have even forgotten some of the real terms that were used to describe that History.

But there is an even more recent shift in the language of the Internet, which creates a distinction between Smilies, and ‘Emojis’. In this context, even many ‘Emoticons’ were really just smilies. Emojis distinguish themselves, in that these pictograms are represented as part of text in the form of Unicode values, of which there is such a large supply, that some Unicode values represent these pictograms, instead of always representing characters of the Earth’s many languages, including Chinese, Korean, Cyrillic, etc. What some readers might ask next could be, ‘Traditionally, text was encoded as 7-bit or 8-bit ASCII, how can 16-bit or 32-bit Unicode characters simply be inserted into that?’ And the short answer is, through either UTF-8 or UTF-16 Encoding. Hence, in a body of text that mainly consists of 8-bit codes, half of which are not normally used, sequences of bytes can be encoded, which can be recognized as special, because their 8-bit values do not correspond to valid ASCII characters, and their sequences complete a Unicode character.

One fact which is good to know about these Emojis is, that they are often proprietary, which means that they are often either the intellectual property of an IT company, or part of an Open-Source project. But the actual aspect of that which can be proprietary is, the way in which Unicode values are rendered to images.

What that means is that, for example, I can put the following code into my blog: 🤐 . That is also referred to as Unicode character ‘U+1F910′. Its length extends beyond 16 bits by 1 bit, and the next 4, most-significant bits are all 1’s, as expressed by the hexadecimal digit ‘F’. It’s supposed to be a pictogram of a deceased entity, as if that were stated correctly by a head which has had certain features crossed out. But for my blog, the use of such a code can be a hazard, because it will not display equally on Android devices, as it displays on iOS devices. And, on certain Linux computers, it might not be rendered at all, instead just resulting in a famous rectangle that seems to have dots or numbers inside it. This latter result will form, when the client-program could not find the correct Font, to convert this code into an image. (:3)

Those fonts are what’s proprietary. And, they also provide some consistency in style, between Android devices, OR between iOS devices, OR between Windows devices, etc.

Well, I began this posting by musing about the early days of the Internet. During those days, some users – myself included 😊  – did some things which were truly foolish, and which included, to put background images into our HTML-composed emails, and, to decorate documents with (8-bit) dingbat fonts, just because it was fun to pass certain fancier documents around, than POT. I don’t think there is really anything wrong with potential readers, who still put background images into their emails. What I mean is that many of my contacts today, prefer emails which are not even HTML.

This earlier practice, of using dingbat fonts etc., tended to play favourably into the hands of the tech giants, because the resulting documents could only be viewed by certain applications. And so today, I needed to ask myself the question, of how often the use of Emojis can actually result in a document, which the recipient cannot read. And my conclusion is that today, such an indecipherable outcome is actually rare. So, how I would put a long story short is to say, that Commercialism is back, riding on the desire of younger people to put more-interesting content into their messages, and perhaps, without some of the younger people being aware that when they put Emojis, they are including themselves as the software-disciples of one larger group or another. But that larger group mainly seems to be drawing its profits, from the ability of certain software to insert the images, rather than, the ability of only certain software to render them at the receiving end (at all). Everybody knows that, even though the input methods on our smart-phones don’t lead to massively good prose, they almost always offer a rich supply of Smilies, plus Emojis, all displayed to the sender using his or her own font, but later displayed to the recipient, using a potentially different font.

The way Linux computers can be given such fonts, is through the installation of packages such as ‘fonts-symbola’ and ‘ttf-ancient-fonts’, or of ‘fonts-noto‘… The main drawback of the open-source ‘Symbola’ font, for example, is simply, that it often gives a more boring depiction of the same Unicode character, than the depiction which the true Colour Noto Font from Google would give.

One interesting way in which Linux users are already in on the party is, in the fact that actual Web-browsers are usually set to download fonts as they are needed, even under Linux, for the display of Web-pages. Yet, email clients do not fall into that category of applications, and whether they render Emojis depends on whether these font packages are installed.

Hence, if the ability to send Emojis from a Linux computer is where it’s at, then this is going to be the subject of the rest of my posting. I can put two and two together, you know…

(Updated 7/31/2020, 15h10… )

## A simple 3D animation created with Maxima.

One of the things which I find myself doing quite often is, to be undertaking some sort of task on the computer(s), that I know is possible, but, not knowing in advance what the correct syntax and semantics are, to perform this task. This tends to take me on some sort of search on the Web, and I’ll find that other people have undertaken similar tasks, but not, a task with the same combination of parameters, as my task.

Thus, Web pages can be found according to which 2D animations have been created using a free, open-source Computer Algebra System named “Maxima”. Other Web pages may explain how to create various types of (static) 3D plots. But there may just be lacking examples out there, on how to create the 3D plot, but to animate it.

Using Maxima, there may be more than one way, such as, to keep refreshing the 3D plot over a time interval. But I find that such solutions tend to be second-rate, because of their use of busy-wait loops, as well as the possibility that they may otherwise be wasteful of computing power. I think that the best way, perhaps, to get Maxima to generate an animated 3D plot, could be, in the form of an animated GIF File (of course, as long as there isn’t an excess of frames to this animation).

Thus, the recipe that seems to work is as such:


load(draw)$scenes: []$

for i thru 20 do (
scenes: append(scenes,
[gr3d(explicit(sin(%pi*(x+(i/10)))*cos(%pi*y),
x, -1, 1, y, -1, 1))]
)
)$draw( delay = 10, file_name = "wavy", terminal = 'animated_gif, scenes )$



The script outputs a file named ‘wavy.gif’ in the same folder, as whatever folder it was originally stored in. In some cases, the GIF File may appear in the user’s home directory, or even, in a temporary directory that’s difficult to find, unless the user also gives a full-path name for the file.

And, this is the GIF File that results:

Caution:

My most recent posting had to do, with a version of Maxima that had been ported to Android. The example above will not work with that version of Maxima. In fact, I can really only be sure that this feature works under Linux, which is the O/S that Maxima was mainly designed to run on. Any directives to ‘plot()’ or ‘draw()’ open a separate GNU-Plot window, which behaves in the predictable way under Linux, including the user’s ability to rotate the 3D plots interactively. AFAIK, commands to change to a non-default ‘terminal’ (for drawing and/or plotting) will fail on other platforms.

But, There is also a Windows or Mac alternative to using this platform, which mainly presents itself in the application ‘wxMaxima’. Here, the functions ‘wxdraw2d()’ and ‘wxdraw3d()’ replace those that open a separate window, and both embed their results in the wxMaxima worksheet. In order to make this more versatile, wxMaxima also offers the functions ‘with_slider_draw()’, ‘with_slider_draw3d()’, ‘wxanimate_draw()’, and ‘wxanimate_draw3d()’.

Potential ‘wxMaxima’ users will find the documentation for how to script that Here.

(Updated 7/06/2020, 15h35… )

## Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

I happen to have an older laptop, which I name ‘Klystron’, that is running Debian 8 / Jessie, with KDE 4 as its desktop manager. Don’t ask me why, but I tend to leave older builds of Linux running on some of my computers, just because they seem to be running without any deficiencies.

That laptop has lousy speakers. I decided a few days ago, that it would benefit, if I could get the 14-band graphical equalizer to work, that is generally available on Linux computers which, like that laptop, use the ‘PulseAudio’ sound server. However, on this old version of Linux, achieving that was a bit harder than it’s supposed to be. Yet, because I succeeded, I felt that I should share with the community, what the steps were, needed to succeed.

First of all, this is what the equalizer looks like, which I can now open on that laptop:

And it works!

In order to get this sort of equalizer working with PulseAudio, eventually, the following two modules need to be loaded:

module-equalizer-sink

module-dbus-protocol

And, if I gave the command ‘load-module…’ naively from the command-line, as user, because under my builds of Linux, PulseAudio runs in user mode, both these modules seem to load fine, without my having to install any additional packages.

On more recent builds of Linux, one needs to install the package ‘pulseaudio-equalizer’ to obtain this feature, or some similarly-named package. But, because these two modules just loaded fine under Debian / Jessie, I guess the functionality once came integrated with PulseAudio.

But I soon started to run in to trouble with these modules, and discovered why, then, the equalizer function was not set up to run out-of-the-box…

(Updated 6/26/2020, 10h30… )

## Changing the <Alt>+(LMB-Drag) behaviour of Linux, under the Plasma 5 desktop manager.

One of the realities of many graphics / editing applications is, that the action to drag either an object or one of its handles with a mouse, or with any other pointing-device, needs to be modified in several ways, depending on what, exactly, the user expects the application to do. I have recently encountered a Web-application, which therefore displays in a Web-browser, in which to hold down the Shift-Key while dragging the corner of a rectangle does one thing, holding down the Ctrl-Key while doing so does another, and holding down the Alt-Key performs yet-another action, which in this case was, to draw an ellipse instead of a rectangle. And in this Web-application, the ability to draw circles or ellipses would eventually become important.

The problem with any application that has this as one of the inputs it accepts, is that such applications were never designed with Linux in mind. The reason is the fact that, under Linux desktop-managers, to <Alt>+(LMB-Drag) gets intercepted, and has as effect to drag the entire application window. That Web-application never receives such a combination of inputs.

Fortunately, if the desktop-manager is one of the ‘Plasma 5′ sub-versions, there is a way to change that behaviour. It can be found under:

System Settings -> Application Style -> Widgets Style and Behaviour -> Applications Tab -> (Breeze Theme from Drop-Down) -> (To the right of the theme chosen from the Drop-Down) Configure… -> General Tab -> Windows’ drag mode -> (From the drop-down) ‘…Titlebar Only’.

That last drop-down is not wide enough to show its full text.

The reason this defaults to ‘Anywhere from within the window’, is a fear that might exist, that an application’s window could end up very-incorrectly positioned on the screen, and that a user might not be able to change that position, by the next time he starts the application. I.e., some applications remember their window-position from one session to the next, and it could be screwed up. If this behaviour is changed, <Alt>+(LMB-Drag) will only drag the window, and therefore be intercepted before it reaches the application, if the mouse-pointer can be positioned over the window’s title-bar.