From: verdy_p (email@example.com)
Date: Wed Jan 06 2010 - 18:20:43 CST
> the same technology was used for underlining text, so there
> was nothing exotic about it
> it wasn't just the special characters, either -- a policy of "visual fidelity" meant that 'F' overstruck with
'L' would be seen by the mainframe as 'E', because that is what the terminal user would see on their printed page
> Backspace does not provide a very sound basis for Ascii Art, however, because it is sometimes destructive and
Do you know that this type of hack found in past national implementations of ISO 646 has been deprecated since long
(and even retired completely by some national entities, such as the older French version of ISO 646 which was
revized to completely forbid this use, even if this meant that some characters with accents could no longer be
Let's not come back to before the 1970's. Backspace is definitely no more recommanded for plain text encoding, and
in many standards using plain text protocols, it is even completely forbidden: this is no longer necessary given
that diacritics have their OWN encoding without using such legacy.
Do uou suggest instead that combining characters ("zero-width") be encoded in addition to the spacing ones for these
drawing characters? Hmmm... Would'nt it add more confusion within plain-texts if these combining characters combine
with other characters than the graphic symbols?
For such symbols, in fact, it would really make more sense to prepare extended sets of symbols (all precomposed) to
fit your needs (such as the diagrams you discussed).
We could effectively have symbols to make for example road direction diagrams (for navigation systems) that can be
juxtapoed easily in a simple square matrix. Some of such symbols have been encoded for compatibility with older
Videotex/Telext systems, or old family computers (with poor graphic support) that used "mosaic" symbols to simulate
graphics mixed in texts using monospaced fonts (generally bitmap fonts).
But all this looks like so old technology. Creating diagrams with juxtaposition of symbols in plain-text is just
poor, when graphics capable displays and printers are now used everywhere (except in some limited technical
consoles). If it still survives, it's because of some ASCII art still found in emails, or because of programming
languages that depend on exact numbers of characters (but even for programming, now I prefer variable-width fonts as
I never need to align columns of data vertically, and also because tabular data files are no longer used : they are
too difficult to edit safely).
Let's leave plain-text in its domain: encoding freely flowable characters to render texts, without dimension
constraints (monospaced fonts are certainly not the best way to render text and it fails in many scripts, where the
result is simply horrible and difficult to read), but not 2D diagrams/graphics with their alignment constraints. The
need for new symbols is still possible provided that they can be used in isolation and without any 2D alignment
constraints (where some diagrams are spanning lines and mixed with text, breaking the logical structure of these
texts, by splitting the effective encoding of the diagram into several parts...
If only all browsers had native support for embedding SVG graphics directly in pages, we could save lots of bitmap
graphics and would also no longer need many new symbols, and the logical structure of documents would be encoded in
a logical way. All encoded symbols should have a meaning by themselves and should be clearly identifiable without
breaking the logical structure of texts.
This archive was generated by hypermail 2.1.5 : Wed Jan 06 2010 - 18:23:15 CST