67
edits
User:Uri/Bidi editing: Difference between revisions
→Switching keyboards
No edit summary |
|||
| Line 55: | Line 55: | ||
Actually, typing is not as simple as described above. Consider The same scenario as above, but this time, instead of pressing "delete", the user types a Hebrew letter (let's say '''X'''). This letter is inserted (logically) between the '''n''' and the '''H''', which means that it will appear visually to the right of the '''H''': '''latinWERBEHXmore'''. Notice that the newly-inserted letter appears away from the visual caret position! | Actually, typing is not as simple as described above. Consider The same scenario as above, but this time, instead of pressing "delete", the user types a Hebrew letter (let's say '''X'''). This letter is inserted (logically) between the '''n''' and the '''H''', which means that it will appear visually to the right of the '''H''': '''latinWERBEHXmore'''. Notice that the newly-inserted letter appears away from the visual caret position! | ||
IBM's algorithm tries to address this issue in two ways: | IBM's algorithm tries to address this issue in two ways: | ||
#It tries to ensure that the keyboard language selection will match the current logical-to-visual mapping. For example, the situation described above will occur when the caret arrived at that position by using the right-arrow to move past the word '''latin'''. In this case, the IBM algorithm specifies that the keyboard | #It tries to ensure that the keyboard language selection will match the current logical-to-visual mapping. For example, the situation described above will occur when the caret arrived at that position by using the right-arrow to move past the word '''latin'''. In this case, the IBM algorithm specifies that the keyboard layout should be set to an LTR layout, so the user will not be able to type a Hebrew letter without manually switching the keyboard layout to Hebrew (similarly, the other visual mapping for the same logical position is triggered by left-arrowing over the Hebrew word, which would set the keyboard layout to Hebrew). ''Note that this part of the IBM algorithm is currently not implemented by Mozilla'' - see [https://bugzilla.mozilla.org/show_bug.cgi?id=162242 bug 162242]. | ||
#When the user does manually switch the keyboard layout, the system adjusts the visual positioning of the caret to match the position in which the next expected character will actually appear. In the example above, if the user switches the keyboard layout from English to Hebrew, the logical-to-visual mapping will be switched so that the caret will be displayed between the '''H''' and the '''m''', so when the '''X''' is typed, it appears at the caret's location. | #When the user does manually switch the keyboard layout, the system adjusts the visual positioning of the caret to match the position in which the next expected character will actually appear. In the example above, if the user switches the keyboard layout from English to Hebrew, the logical-to-visual mapping will be switched so that the caret will be displayed between the '''H''' and the '''m''', so when the '''X''' is typed, it appears at the caret's location. | ||
Note that the combination of these two methods still doesn't solve the problem entirely. It's possible for the user to type LTR characters (such as numbers) when the keyboard layout is Hebrew, ot to type neutral characters, which will become part of an RTL run, while the keyboard layout is English. I'll get back to this in the next section. | Note that the combination of these two methods still doesn't solve the problem entirely. It's possible for the user to type LTR characters (such as numbers) when the keyboard layout is Hebrew, ot to type neutral characters, which will become part of an RTL run, while the keyboard layout is English. I'll get back to this in the next section. | ||