resource update

Brian Davidson

In what way were QSM and BHW just updated?

Vincent Setterholm

Two issues, both to do with holem-waw:

1) I found (and fixed) a bug in some older code that left a few holem-waws in the 'old' encoding order (U+05B9, U+05D5) instead of the current standard (U+05D5, U+05B9). The affected words would display fine either way, but if one were running a [match vowels] search, or any broader [match] category that includes [match vowels], such as [match pointed], [match cantillated] and [match exact], and typing in Hebrew instead of copy|pasting, some words could have tripped the user up with a non-standard encoding order. (We do normalize search input and run that against normalized strings in the index, so in general it is not necessary to type in marks in exactly the same order we encode them, but in this case, because the vowel was encoded before the consonant, it was being normalized in relation to the previous consonant, so normalization doesn't make the issue go away).

2) I worked with Dev to add support for the left-shifted holem-haser-for-waw (U+05BA) to Logos 5.2b (in beta), so I implemented that mark here as a test case. In previous versions, U+05B9 and U+05BA were treated as completely distinct vowels, which meant that any [match vowels] search would require the user to type the 'correct' holem - which is problematic, since most Hebrew keyboards don't even include this mark. In 5.2b, U+05B9 and U+05BA are treated as the same mark unless [match holemhaser] or [match exact] are used, allowing us to adopt this cosmetic convention without making searching more onerous.

(We did make other improvements to the [match] syntax for 5.2b as well. Some of the broader [match] categories were incorrectly ignoring sin/shin dots, for example, so those functions will be improved.)