An exercise at converting an arbitrary video clip into ASCII-art.

One of the throw-back activities in Computing, which has existed since the 1990s, was so-called ‘ASCII-Art’, in which regular characters represented an image.

When this form of Art is created by a Human, it can look quite nice. But, if a mere computer program is given a sequence of images to convert into characters in a batch-process, the results are usually inferior, because all the program will be able to do is, to translate each cell of the images to an ASCII character, the brightness of which is supposed to represent the original brightness of the cell of the image. The complex shape of the actual text characters is not taken into account – at least, by any programs I have access to – and will also interfere with the viewer’s ability to recognize the intended image, because those shapes will just represent some random ‘noise’ in the image, without which, merely to have been given grey-scale tiles would have probably made it easier for the viewer to recognize the image.

In spite of recognizing this, I have persevered, and converted an arbitrary video-clip of mine into ASCII-art, programmatically. The following is the link by which it can be viewed:

(Link within my Web-site.)

And Yes, the viewer would need to enable JavaScript from my site, in order to obtain an actual animation, because that is what advances the actual ‘iframe’.

 

(Updated 6/24/2021, 22h30… )

Continue reading An exercise at converting an arbitrary video clip into ASCII-art.

Some perceivable inconsistencies, about whether the embedded worksheets can be viewed.

One of the facts which I did mention in an earlier posting, concern worksheets which I sometimes embedded into my postings as ‘<iframe>s’. In reality, there could be two reasons, why such worksheets fail to display in any one person’s browser:

  1. I could have embedded them, specifying (insecure) URLs that begin with ‘http://’, even though the reader may be visiting my blog, using a (secure) URL that begins with ‘httpS://’. Or,
  2. The posting might suggest that the reader “may need to” enable JavaScript from the domain ‘mathjax.org’, but, in certain cases this is not needed, while in other cases, it is.

‘Problem 1′ above is harder for the reader to fix at their end. It can be solved by fetching my posting using the insecure ‘http://’ URL, or, as I’ve done in a very recent posting, I could decide to embed the ‘<iframe>’ using a URL, which does not specify my domain-name, and just assumes that it’s to be the same, as the domain-name of my site.

‘Problem 2′ above represents a contradiction which may confuse some readers. Sometimes, when I generated an HTML version of a worksheet, I did this by simply clicking on a button, in the GUI of my software. In such cases, the HTML will require that the JavaScript be enabled. But, in certain other cases, all I really did was, to output the worksheet as a LaTeX document, and then to run a custom script on it, to generate other types of documents, one of which would have been an HTML document.

If I ran my custom script on some generic LaTeX document, that generates ‘HTML with equations’, it will do so in the form of ‘a hybrid document’. The resulting document is hybrid, because it can then be viewed in one of two ways:

  1. Using the built-in support for ‘MathML’, that some readers’ browsers have. This is less likely, because I only know of one browser that actually support it: ‘Firefox’. If the reader is using ‘MS Edge’ or the ‘Chrome’ browser to view my posting, I know that they do not support MathML as a built-in feature. But,
  2. Such a hybrid HTML document can also be viewed, by enabling the JavaScript that gets referred to as ‘MathJax’, and which essentially allows other browsers, including ‘MS Edge’ and ‘Chrome’, to view the equations.

I try to accommodate as many possible configurations of the readers’ browsers as I can, but the unfortunate reality is, that merely pressing the GUI button within my application, may generate HTML which is highlighted more nicely, but which is not a hybrid HTML document.

Dirk

 

Just Created a Working Instance of TinyMCE

One of the more-interesting features of JavaScript in years gone by, was the in-browser HTML editor named ‘TinyMCE’. What this scriptlet does, is run on the browser, and allow people to edit the contents of a <textarea>, in WYSIWYG style, for submission to an arbitrary Web-application.

For me, this piece of JavaScript has little use. Other Web-applications of mine, already give me HTML editing which is rich enough, not to depend on TinyMCE. But there has been a facet of this scriptlet, which has irked beginning-users and Web-designers so far, which is that by default, it offers no ‘Save’ Menu-entry. The reason it does not is twofold:

  1. TinyMCE is meant to be integrated into some more-complex Web-page, where its input is also given a defined purpose, and
  2. By itself, this scriptlet just runs on the browser, from where it has no privilege to store its edited contents anywhere, neither on the server, nor on the client-machine running the browser.

And so some people have wondered, how they could exploit this amazing technology, just to save the edited HTML locally, to the hard-drive of the computer running the browser. And there are many possible ways to solve that problem, out of which I’ve just implemented one:

It’s possible to add a ‘Submit’ button, which sends the edited content to the server, which can in turn display it as a Web-page, that the user can save to his hard drive, using the “Save Page As…” Menu-command belonging to his browser. I cannot think of a solution that would be easier. However, if somebody wanted to use this mechanism, then next, he’d also need to open the .HTML-File saved to his hard-drive, and edit out the parts of it, that make it a Web-page, thus editing the saved HTML-File down to just the part that displays between the <body>…</body> tags.

https://dirkmittler.homeip.net/tinymce/plugin/tinymce

Enjoy.

(Update 2018/08/13 : )

Because this example of JavaScript sends the text to my server, which echos it back to the browser, I suppose that in theory I could reprogram my CGI-script, to keep a complete record of all the text-fragments submitted. But in practice, I see no point in doing so, and therefore also keep no record of what has been typed.

In addition, because I’ve suggested the URL as an ‘httpS://’ URL, a Secure Socket Layer gets used, so that No user will need to worry about the communication itself, to and from my server, being monitored by any third party.

Dirk