Simon013 - More tolerant glyph look-up a1 -> A1 [DONE]

Bonjour Serge

I do not see a real necessity for forcing the user to key in Y1v when y1v or Y1V would have done the job. The look-up should be more tolerant.

First - Y1v should become Y1V - all the other Gardiner IDs have an upper case variant letter. This lower case "v" is inconsistent. Any other such cases should be treated similarly.

If you do not want to implement changes such as Y!v to Y1V, then this should be done during the compare itself if there is a digit in the search argument.Then you would have to implement a look-up on the basis of a toUpper comparison - i.e. the toUpper(arg) and the toUpper(Gardiner or whatever). See Solution 3.

Here is what I am aiming at:

aA -> aA
A1 -> A1
a1 -> A1
aa1 -> Aa1

Then there are three solutions:

=========================================

Solution 1:

if search_arg contains digit then search_arg=toUpper(search_arg)
result=lookup(search_arg)

For Aa## you would have to add an extra thingy.

This solution may have implications for users defining new signs. In this case, if a user defines a z999 it must go through the same conversion rules - i.e. be converted to Z999

=========================================

Solution 2

result=lookup(search_arg)
if not result then
if search_arg contains digit then
result=lookup(toUpper(search_arg))
end
end

The second solution is safer for future developments or if there are cases where numbers are parts of search arguments - maybe in conjunction with the 1, 2, 3 and 4 - actually signs. However, I do not think that this is the case.

Obviously, even more complicated approaches can be taken.

=========================================

Solution 3

Taking things even further.

result=lookup(arg) # this is the look-up you have now
if not result then result=uppercase_lookup(arg) # new look-up with an ignore shift comparision

This would be even more useful and not be restricted to Gardiner IDs. "aa" would find "aA". On the other hand, "ta" or "TA" would find "tA" and "Ta" and TA. The question is whether, in this latter case, this look-up tolerance is really still so useful. I think yes. After all, this only happens if the first look-up fails. If I key in correctly, I get exactly what I expect. If I don't, JSesh does its best to find something for me. You could implement this type of operation as an option in Preferences. As far as Gardiner IDs are concerned, I thing it should always be activated.

Then we get

result=lookup(arg)
if not result then
if arg_contains_digit OR option_set then result=uppercase_lookup(arg)
end

Apart from that, there should be some element of the GUI telling me that there are multiple solutions to my look-up. At the moment you only see this by depressing the space bar, or by looking at the resultant glyph. It might be a good idea to show the user somehow that there are actually alternatives to be had - either real variants or language based ambiguities, or pseudo-alternatives due to duplicate search args having been set up.

=========================================

It goes without saying, that in all cases the MdC output should be using the correct letter shifts.

The above suggestion greatly improves the usability. The necessity of more than half of the shift-key usage simply vanishes into thin air.

Cordialement,
Simon

I agree

Simon,
I do agree that sign-typing should be more tolerant and intuitive, regardless of the case.

Carlos Moreira
Portugal

I put this on the "to-do" list

Well, it's very easy to add this functionality in the current version of JSesh, and it's certainly a good idea (for "Gardiner codes". I would be more reluctant for translitteration, as "a" and "A" are really different).

Actually, that's an example of what new users can bring to a software. Being a user of the Manuel de Codage in text only mode since 1993 (or maybe 1992, can't remember exactly when I created the first version of HieroTeX), I'm so used to typing the exact codes that it did not even occur to me that "a1" would be easier to type than "A1".

So, if you feel some operation is unnecessarily complex in JSesh, feel free to tell it, you may be right/

Serge Rosmorduc

Done in JSesh 6.0.0

The title says it all :-)
Serge Rosmorduc