OverStrike control character
Joao S. O. Bueno
gwidion at gmail.com
Fri Jun 19 10:11:58 CDT 2020
Since this discussion has come this far, I will drop my 0.02 :
I am currently authoring a library/framework to create character art
("ASCII art") - as a free software project, including drawing APIs
using block characters, and helpers for using emoji.
In this position, such a character combination would be
a "nice to have" - and if it would not disturb other aspects of
text-communication, I am all for it.
Fact is one would still need a terminal app to support it properly,
but, my project can also work with other backends for rendering
Currently it supports ANSI-sequence texts aimed at terminal emulators
and an HTML output based on monospaced fonts and CSS stylling.
But pixel-based backends are on the roadmap, and easy to do.
I see this library and similar projects as major users of the
"overstrike" features. In the case of my project even as
an enabler for other people to use it.
However, as it is obvious, I have to count on higher level protocols
to specify in-string text attributes, and I can make use of those
for overriding character positioning with no need of an special
character for overstrike.
So, although my project could support this, and having some people
using the overstrike character for some simplified output, it will certainly
also integrate in-string markup for other positioning control (by
I was coding exactly this part last night) .
On the other hand if overstrike character is ever implemented and
terminals and other text APIs in popular toolkits such as Qt/GTK I can get
character artistic effects on those backends as well, instead of limiting
to pixel-based backends.
(If anyone is curious about it, the project url is
and I can get help with having more unicode compliant
internal names and APIs, as well as help other people
for whom the project tools might be useful)
On Fri, 19 Jun 2020 at 11:48, Richard Wordingham via Unicode <
unicode at unicode.org> wrote:
> On Fri, 19 Jun 2020 11:40:01 +0000
> James Kass via Unicode <unicode at unicode.org> wrote:
> > A font could be designed to make appropriate glyph substitutions for
> > strings which include the control picture for backspace, U+2408
> > (“␈”). So a font could substitute an over struck l-m glyph for the
> > string “l” + “␈” + “m”. If the font didn’t support that string, the
> > default display would still show authorial intent. In this way users
> > desiring to exchange data in plain-text which included over-strikes
> > could do so without any additions to TUS.
> Wouldn't this violate the character identity of U+2408?
> The proper mechanism would be to use a PUA character. The question is
> whether the font would be enough, or whether one would have to change
> its invoker.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unicode