[sword-devel] NASB Lexicons

[Daniel Glassey]

On Wed, 2004-07-21 at 16:25, David wrote:
> Anthony,
> 
> Your image shows the character that I can't find in the unicode standard.
> The dots that looks like Sheva within the Final Kaf on the image, if we could
> find the unicode value of that character the problem could be fixed, assuming
> that it is in the unicode standard. I went to the SIL site, and could not find
> the character in the SIL Ezra documentation.
> http://scripts.sil.org/cms/scripts/render_download.php?site_id=nrsi&format=file&media_id=HebUniKeyboard.pdf

Er, if it looks like "Sheva within the Final Kaf" then maybe that's what
it is? (IANAHE[1]) As Anthony says, it is probably the OpenType features
that position the Sheva correctly within the final kaf. Or does sheva
appear below the final kaf in other circumstances?

Aha, found something
http://lists.ibiblio.org/pipermail/biblical-languages/2002-March/000408.html

"and b) we now can use OpenType features to get things like sheva
rising up into final kaf automatically."

I'd say the best thing is to put them back and leave it to the programs
to decide how to render them.

It will need to go in documentation to say that Ezra SIL or another
OpenType Hebrew font is recommended for the Hebrew lexicon.

> If you could extract the unicode value from the text that your snapshot shows, I
> could look in the unicode pdf's to see if it does exist in the standard.
> 
> This link mentions a character not specified in the unicode standard in SIL
> Ezra.
> 
> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=ReversedNun_intheBHS
> 
> This maybe the case with the character I can not find in the unicode standard,
> but appears to exist in SIL Ezra. I can understand this being done in order to
> create what is needed, but I am not sure that it would be acceptable to encode
> text with anything that is non-standard unicode in this situation. That kind of
> negates the idea of unicode.

No, afaiu if a character isn't in Unicode™ and you need to use it the
thing to do is to put it in the Unicode PUA (Private Use Area) in a
specified way and use it from there until it gets accepted into Unicode
(which is a very long process). That is what they have done (as well as
a hack in the font to make nun+ CGJ (0x034F) + dot (0x0307) also be
reversed nun).
What's your alternative to doing that?

Regards,
Daniel

[1] I am not a Hebrew expert. 

P.S. Congratulations on the baby Anthony :)


> And congratulations on the baby.
> 
> David
> 
> Quoting anthony kerr <anton_kylie at pacific.net.au>:
> 
> > David
> >
> > I am not a hebrew expert, but am studying Hebrew in 2nd year of college.
> >
> > Using Bibletime CVS, and in fact most KDE apps since a recent upgrade, and
> > using SIL Ezra unicode Font my Hebrew Module shows final kaf perfectly.
> >
> > I put a small screen shot up on my server at
> > http://www.jesuscentral.net/images/snapshot1.jpg - this is the latest hebrew
> > module WLC.
> >
> > I think the trick was QT being able to read the OpenType features of the SIL
> > Ezra font. I think that most people who do Hebrew are sticklers for detail,
> > (you have to be to get all the pointing right) therefore it would be best to
> > encode things correctly and let the window managers sort it out. That is my
> > perspective anyway, for what its worth.
> >
> > I am not really in the right frame of mind to fully follow all of the
> > codepoint stuff at the moment because my wife gave birth to our first child
> > yesterday and God has blessed with a lovely little daughter.
> >
> > But feel free to email me in the next few days if what I said above isn't of
> > any help.
> >
> > in Christ
> > anthony kerr
> >
> >
> > On Wed, 21 Jul 2004 11:21 am, David wrote:
> > > The only remaining problems with the NASB is to have someone more qualified
> > > than myself to examine the conversions from the Hebrew, and Greek fonts to
> > > unicode. There 79 characters used in the Greek lexicon, and 88 used in the
> > > Hebrew. Many of those are alphabetic, or are very distinct in appearance
> > > and easily checked. In some cases there are multiple characters with very
> > > close to the same appearance. This is what mainly needs to be checked.
> > >
> > > Other than that I believe that all problems with the lexicons have been
> > > handled.
> > >
> > > There some problems that could not be fixed. There is a precomposed
> > > character in the original font (74) Final Kaf with a character that appears
> > > something like Sheva, except aligns within Final Kaf instead of below, the
> > > character does not exist in the unicode specification alone, or precomposed
> > > with Final Kaf. Instead of deleting the character I replaced it with Sof
> > > Pasuq, it probably will not make much difference to people that can't read
> > > Hebrew, and people who do will probably realize there is a problem, and
> > > since Sof Pasuq appears similar to the missing character it may help them
> > > realize what the problem is.
> > >
> > > The multiple entries for a number have been handled by keeping them in one
> > > entry, and adding seperate entries for each subentry. As Troy, and Chris
> > > both suggested. Although I am not sure if there was any final decision on
> > > it.
> > >
> > > 00112:
> > > 112a.
> > > 112b.
> > >
> > > 00112a:
> > > 112a.
> > >
> > > 00112b:
> > > 112b.
> > >
> > > If anyone has any ideas of how to handle the Final Kaf problem in a better
> > > way, or wants to check the conversion routines let me know.
> > >
> > > David

>