From: saqqara (saqqara@csi.com)
Date: Sun Mar 06 2005 - 10:54:02 CST
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