Re: Combining Box Characters?

From: verdy_p (
Date: Wed Jan 06 2010 - 18:20:43 CST

  • Next message: Curtis Clark: "Re: Quick Question About Korean Input Methods"

    "philip chastney"

    > 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
    sometimes not 

    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