From: Karljürgen Feuerherm (cuneiform@rogers.com)
Date: Sat Jul 26 2003 - 09:10:13 EDT
Assuming I've understood you correctly.... It should be as transparent as
possible. Biblical scholars are not *necessarily* technically savvy. Witness
the fact that a number of my colleagues still type Hebrew 'backwards' using
old legacy systems.... One should not presume technical prowess, at best
Biblical literacy.
K
----- Original Message -----
From: "Jony Rosenne" <rosennej@qsm.co.il>
To: <unicode@unicode.org>
Sent: Saturday, July 26, 2003 2:27 AM
Subject: RE: Yerushala(y)im - or Biblical Hebrew
> I don't think that it is important that the user not be aware of the
> encoding, since it is only intended for Biblical scholars.
>
> Jony
>
> > -----Original Message-----
> > From: unicode-bounce@unicode.org
> > [mailto:unicode-bounce@unicode.org] On Behalf Of Kenneth Whistler
> > Sent: Saturday, July 26, 2003 3:50 AM
> > To: Peter_Constable@sil.org
> > Cc: unicode@unicode.org; kenw@sybase.com
> > Subject: Re: Yerushala(y)im - or Biblical Hebrew
> >
> >
> > Peter wrote:
> >
> > > One thought: Ken has suggested CGJ be used to prevent reordering of
> > > combining marks in fixed position classes such as the
> > Hebrew vowels,
> > > and also suggested that users should not need to be aware
> > of the need
> > > for CGJ for this purpose but that software can be
> > implemented in a way
> > > that hides that detail. I'm not sure how that will work,
> >
> > Details TBD, of course, but the essence of it is that you
> > want the user experience of inserting patah + hiriq
> > to correspond to the backing store insertion of <patah, CGJ,
> > hiriq>, without making them explicitly have to know about or
> > type a "CGJ" key. There are various input and editing
> > strategies to accomplish this -- effectively the problem is
> > similar to other needs to tuck hidden characters away in the
> > backing store for bidirectional text.
> >
> > The situation for searching is a little different. While the
> > editing tools may be smart about the Biblical Hebrew points,
> > a typical query widget might not, so in that instance, you
> > want a query on <patah, hiriq> to match the repository store
> > instance of <patah, CGJ, hiriq>. Well, format controls and
> > some other characters (including CGJ) are ordinarily supposed
> > to be ignored for searching -- unless you have specialized
> > tailorings for them. So the ordinary strategy would be to
> > keep the repository normalized, and then before local
> > comparison against the query string, strip out the CGJ for
> > the match. The situation is more complicated if the query
> > string doesn't use a CGJ *and* gets normalized. In that
> > situation, you lose the distinction in order, of course, but
> > the search strategy should be to strip out the CGJ locally
> > and renormalize. That could result in false positive matches,
> > of course, but at least you will find what you were looking for.
> >
> > > but it's making me wonder if
> > > effectively we'd be looking at some amendment to the normalization
> > > algorithms to insert CGJ in certain enumerated contexts.
> >
> > No.
> >
> > --Ken
> >
> >
> >
> >
> >
>
>
This archive was generated by hypermail 2.1.5 : Sat Jul 26 2003 - 09:58:36 EDT