Comments
Let me first say the new 'Word Info' for BHS on IOS is very good. It took a little getting used to but I have the hang of it now. Good job guys.
Unfortunately there does not seem to be a 'Report typo' for BHS in Logos Bible Study 39.1 39.1.6
If someone has a better mechanism I would love to hear it.
So I offer the following screen shots. First is Logos BHS/WHM 4.2 and second my physical BHS (sorry for the size…not sure how to control that)
The problem is that Logos has a 'resh' where there should be a 'waw' in the second word of 1 Samuel 22:13.
Interesting. I checked a few other Hebrew texts and they were correct, including BHS/WIVU and LHB but I do like the morphology in BHS/WHM 4.2. Its also wrong in BHS/WHM 3.5.
Shalom Paul,
First of all thank you for taking the time to report a typo. However, I am afraid I have to tell you that in this case your effort has been in vain. The resource you are using has been deprecated. Logos is currently selling BHW 4.18 which is a significantly newer version than 4.2:
Also note that this resource is not called BHS anymore. Even the earlier versions you are using (3.5 & 4.2) contain changes to the text of BHS.
In the future you might want to write a new post instead of replying to a thread that is already more than 10 years old.
Nice to hear that you like the new "word info" on mobile devices.
It's not a typo. The typographic distinction between holem-waw and waw+holem, where the latter has the holem dot shifted slightly to the left, is an optional convention. There was no support for it until Unicode 5, and as such it has some compatibility issues (not just at the level of some fonts not supporting the new holem code point - SBL Hebrew does, but also issues relating to how you search the new mark - is the user required to type the correct holem in order to find the word they are looking for or are the marks treated identically for the purposes of indexing/searching? It seems obvious that for 99% of users, 99% of the time, you'd want to treat these marks as the same for everything but display, but do we need to encode a new match syntax to make it possible to find just the one or the other for the people who care? Does '[match all]' really match all, or is this left as an exception to the rule without another flag like '[match all, holem]'? How about for KeyLinking and lexicon navigation - do we need to write additional code to support working around the change? Does the text comparison tool need code to ignore these cosmetic differences when comparing two texts? It might turn out that none of that is terribly difficult to handle, but it would all have to be tested.)
A bigger issue for us is that none of our databases come from Unicode source files and they don't distinguish between the two holem characters, so it would be an exercise for us (OK, me) to determine which character to use where. Now I might be wrong about that - some of the source files might encode the difference, but in a fairly non-obvious, non-Unicode way, where the trick is to look at each holem and ask 'is this on a waw (checking for intervening characters, like dagesh)?' and then treat it differently if the answer is 'yes' because the combination holem-waw is consistently handled with a completely different mark. Or perhaps the source file encodes the different in order (OW vs. WO) and our code carefully obliterates this difference to get the characters in proper Unicode order, which would mean rewriting the code we use to convert the source files to intercept 'WO' differently without breaking the proper conversion of 'OW'. In the absence of a consistent code in the source files, I could easily write a script that could catch 95% or more of these, but then you run into sequences like hireq+yodh+waw+holem and there isn't a programmatic way to know if this is i/yo or iy/wo. If you're lucky, there might be the right type of accent directly on the yodh or the waw which clears the matter up, but if not, I'd have to appeal to some other authority to look up which way to read it. Which, of course, I could do. My point isn't to make this seem unsolvable, just time consuming and I haven't decided if the pain is worth it for a non-standard typographic feature that is only partially supported. In your Genesis example, there is only one way to read that word - it's really only in the tricky sequences where the effort pays off, so an automated solution that only gets it right say 98% of the time isn't really very compelling to me.
But I'll think about it some more. I'm supposed to be getting new SESB files sometime soon, and that'll give me an excuse to look at those source files again and see if they have actually made all the editorial decisions in a way that we simply ignored because before Unicode 5 there was only one proper way to handle this. If so, maybe I'll try building it with two different holem code points and see how well it works in our system.
I had a peek at a certain bible application (a 2004 version), and see that Gen 37:10 is set out correctly.
It's not my place to confirm whether their database is Unicode-kosher or not. If it is, I'm not sure whether their database was only patched post-Unicode 5 (2006) to show it correctly (what I know is that database patches come fast and furious), Fact is, they've got the text right.
I expected a "thanks for the typo report". Never expected the kind of reply I got. You want to market a "program for scholars etc..." like that?
I'd be happy enough with an accurate digital representation of the printed version!
Vav-holem-tav a partially supported typographic feature? I thought rather naively that Logos is here to save my time, not Logos'.
Sorry, Lee. I mistakenly thought you'd find the details interesting. I didn't mean to give the impression that I was minimizing your request. I did say I'd look into it.
Vincent,
Thanks so much for the detailed response! One of my favorite things about Logos as a company is that you guys do such a good job of giving thoughtful and thorough responses to questions that are asked. It really is appreciated. Keep up the great work!
Apology accepted. I did find the details interesting. Unicode has had a fun ride with many languages! But some of the thinking expressed in your post, I'll just state I'm not in agreement with. I do hope something can be done to make the database more precise, as precise as possible, in due course.
Vincent, thanks for the details. VERY interesting.
brianwdavidson.com