Re: proposal for the inclusion of the most basic outlining commands as characters

From: Kent Karlsson (kent.karlsson14@comhem.se)
Date: Tue Apr 14 2009 - 13:04:43 CDT

  • Next message: Don Osborn: "RE: VOA- utf-8, lang="en" (Re: BBC.co.uk languages ...)"

    See
    http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf
    (fast-tracked precursor to ISO/IEC 6429:1992, Information technology --
    Control functions for coded character sets, Edition: 3;
    http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnum
    ber=12782).

    You would find interesting
    SGR - SELECT GRAPHIC RENDITION,
    FNT - FONT SELECTION,
    GCC - GRAPHIC CHARACTER COMBINATION,
    GSM - GRAPHIC SIZE MODIFICATION,
    GSS - GRAPHIC SIZE SELECTION,
    HPA - CHARACTER POSITION ABSOLUTE,
    and more.

    Like ISO 2022, ECMA/48 (ISO/IEC 6429) uses escape sequences, and also like
    ISO 2022, it is not much supported (nor do I think those escape sequences
    should be more supported).

        /kent k

    Den 2009-04-14 01.34, skrev "Dennis Heuer" <dh@triple-media.com>:

    > hello
    >
    > there is a general problem when preparing text: though everybody agrees
    > that the weighted use of some basic typographic formatting commands
    > (italic, underlined, of certain font size (by value and by step), etc.)
    > makes text more readable (and more pleasing than formatting text with
    > plain ASCII characters, as is the case in programming scripts), the use
    > of this formatting commands is not feasible in all cases because the
    > commands are not defined as general font symbols but as part of
    > document formats.
    >
    > this is a sad thing because these commands are as important to text as
    > the delete key, which is defined in unicode, for example. not having
    > these commands generally available means that typographic information
    > might get lost when storing text in a different format. it also means
    > that innovative new ways of using text always again must provide special
    > data formats and input codes (think of wiki and blog editors, for
    > example.) programming code documentation tools would profit from the
    > availability of information about the importance or weight of a text
    > part too.
    >
    > most simple text editors are actually capable of showing bold font etc.
    > because of the toolkits they use. the reason why they can't provide
    > such features is: they rely on plain text files. other editors, like
    > commandline editors, may not be capable of showing the formatting but
    > they can show symbols instead, which means that the formatting is still
    > 'visible'--and the commandline editors will handle this extra
    > information correctly, including saving it back to the text file.
    >
    > this is why i think that the most neccessary typographic formatting
    > commands should be available as both control characters and typographic
    > characters in unicode. text processing systems will understand the
    > control characters and commandline editors will show the typographic
    > equivalents.
    >
    > regards,
    > dennis heuer
    >

    This archive was generated by hypermail 2.1.5 : Tue Apr 14 2009 - 13:13:04 CDT