Re: Encoded rendering instructions (was Unicode's Mandate)

From: saqqara (saqqara@csi.com)
Date: Sun Mar 06 2005 - 10:54:02 CST

  • Next message: Peter Kirk: "Re: CGJ for Two Greek Ligatures?"

    A similar scheme is in standard use for Egyptian Hieroglyphs using four
    quadrants (ie a 2x2 matrix rather than this 3x3 suggestion). I have included
    this in the EGPZ private use specification for hieroglyphs
    www.gameset.com/resources/unicode/egpz.html. The N1944 proposal for Egyptian
    Hieroglyphs in Unicode also included these modifiers although I understand
    these did not find much favour with UTC those several years ago.

    I share your view that something along these lines is useful for
    'programmatic processing of ancient texts', indeed for other purposes where
    transcription is uncertain due to the nature of the source material. The
    notion of character uncertainty is not unreasonable to consider at the level
    of plain text as part of Unicode.

    Although text rendering is a useful application of such a system, another
    rationale for Unicode inclusion is the need to distinguish uncertain
    characters in an unambigous notation: For example "f[o?]r" != "for" (perhaps
    actually a misreading of "fur").

    Bob Richmond
    Saqqara Technology

    ----- Original Message -----
    From: "Dean Snyder" <dean.snyder@jhu.edu>
    To: "Unicode List" <unicode@unicode.org>
    Sent: Saturday, March 05, 2005 11:03 PM
    Subject: Encoded rendering instructions (was Unicode's Mandate)

    >
    > Peter Constable wrote at 9:22 AM on Saturday, March 5, 2005:
    >
    > >>Jon Hanna wrote at 3:15 PM on Saturday, March 5, 2005:
    > >>
    > >>>UList Doug wrote at 1:15 AM on Saturday, March 5, 2005:
    > >>>I would love "flexibility" like an "eXtensible Glyph Format".
    > >>
    > >>Sounds like an interesting idea.
    > >
    > >No, it sounds completely meaningless. ...
    >
    >
    > [And yet Peter continues:]
    >
    > >I suppose if he was referring to a format for representing
    > >meta-information about abstract glyphs, then extensibility could make
    > >sense since there may be all kinds of arbitrary information about a
    > >glyph that someone may wish to record. ...
    >
    > Which brings up something I have been pondering for some time.
    >
    > In transcriptions of damaged ancient texts it is important and useful to
    > indicate roughly the extent of damage to a glyph. Of course, this is not
    > a substitute for direct examination of the original document, but it is a
    > useful property for programmatic processing of ancient texts and their
    > approximate renderings.
    >
    > Currently there are various competing, proprietary systems for indicating
    > glyph damage, using combining marks, punctuation, or markup. I've been
    > wondering if it made sense to actually encode a standard set of rendering
    > instructions so text rendering engines and/or fonts can appropriately
    > draw designated portions of damaged glyphs in plain text.
    >
    > For my purposes I envision a set of nine characters that specify what
    > areas should be subtracted from, or de-emphasized in, the glyph when
    rendered:
    >
    > * upper left corner
    > * upper center
    > * upper right corner
    > * right center
    > * lower right corner
    > * lower center
    > * lower left corner
    > * left center
    > * center
    >
    > The rules for their use are rather simple:
    >
    > a) These rendering instruction characters would precede the visible
    > character they modify.
    > b) Any number of them can be used, disallowing duplicates.
    > c} Any order is allowed, with ordering being insignificant.
    >
    > So I have two questions:
    >
    > 1) What do you think from an encoding point of view?
    >
    > 2) Would any of the major text rendering systems even consider
    > implementing such a system if it were encoded? By implement, I mean, for
    > example, in plain text draw all of the letter "A" as normal, except its
    > lower right corner in a lighter shade to indicate damage there.
    >
    >
    > Respectfully,
    >
    > Dean A. Snyder
    >
    > Assistant Research Scholar
    > Manager, Digital Hammurabi Project
    > Computer Science Department
    > Whiting School of Engineering
    > 218C New Engineering Building
    > 3400 North Charles Street
    > Johns Hopkins University
    > Baltimore, Maryland, USA 21218
    >
    > office: 410 516-6850
    > cell: 717 817-4897
    > www.jhu.edu/digitalhammurabi/
    > http://users.adelphia.net/~deansnyder/
    >



    This archive was generated by hypermail 2.1.5 : Sun Mar 06 2005 - 10:55:21 CST