Dear BrailleNote users, HumanWare Staff and others,
For BN listers: I'm copying HW Tech Support on this post
regarding the issue described in the subject line.
As one of the BrailleNote user pointed out and since it was
discussed on forums and confirmed by at least two others, I feel
it'd be safe to bring some testing results and hyotheses to HW
staff's table in the hopes that the "exception error" pertaining
to Unicode Tables would be resolved soon.
As you may know, Unicode characters allows one to type a wide
range of symbols using braille characters and display them on a
braille display (on models with braille display output). For
instance, this facility allows math and science symbols such as
ones used in advanced math to be manipulated on the BrailleNote,
characters written in other languages such as Spanish to be typed
on the BN and so forth.
One of the features of KeySoft is being able to assign custom
keyboard bindings or macros (on a QT) for a Unicode character, as
well as display this character using the braille dot combination
of users' choosing. For example, in American version of Spanish
braille, one would assign DOTS 2-3-4-6-8 to be assigned to e
acute and display this character on the braille displayusing this
dot combination pattern. On a braille keyboard, this procedure
allows up to 256 different combinations (including default
braille character bindings and display pattern) to be assigned to
different characters (usually about 128 or more different
combinations when using eight dot mode).
ON the BrailleNote Apex, one can assign custom key combinations
to any Unicode character. However, with recent KeySoft releases
for the Apex, when attempting to assign custom braille dot
combinations for the character to be displayed on the braille
display, KeySoft generates the following message:
"exception: command: 404 at 3595. Access violation reading 0."
This message appears when a user has some custom key bindings and
braille display patterns for some characters already and wishes
to add some more after exiting Unicode Tables list (by which time
KeySoft creates "custom USA" or other custom computer braille
tables).
In regards to solutions to this issue that was discussed on the
forums, one proposal was to use mPower's Unicode Tables file and
any existing custom computer braille files and copying them over
to Apex. Another solution was to delete Unicode Tables and
custom computer braille files from the Apex and restoring default
files from ROM image (via a command from Support Information
Mode). Yet another solution was to change the computer braille
table to something other than the custom braille table, which
meant the user has to reassign key bindings and display patterns
from scratch. A fourth solution was to manually edit the custom
computer braille file (stored in Dictionaries folder on Flash
Disk) from within word processor itself by adding display
patterns to new characters at the end of the file. Of these four
approaches, the third and fourth solution would be the best route
depending on whether the user wishes to keep the already assigned
key combinations and/or braille display dot patterns or not.
For the root cause of this issue, I hypothesize that it has
something to do with file reads and information stored on the
custom computer braille table itself. This is supported by the
following facts (mostly for programmers):
* We know that in order to change a KeySoft setting (including
Unicode character key combination/ddplay pattern assignment), we
need to read and modify system files stored on Flash Disk
(specifically, files stored on Dictionaries folder).
* A typical file ends with a NULL (or end of file) marker,
possible because of the fact that, in computing, a string is a
NULL-TERMINATED array of characters and files store characters to
be interpreted by programs.
* When a computer wishes to use a resource such as a file, it'll
query its address, and addresses would store information that the
computer (BrailleNote) is looking for.
* When managing addresses and data on a computer (including a
BrailleNote), one must be careful when: the address that the Apex
wishes to use does not contain vital data that other programs
use, and that attempting to read (called "dereferencing") a NULL
data would result in segmentation fault and exception message to
be displayed.
* When a file (stream) is read, the program that reads a certain
file would work only with things already present in the file.
Thus, when trying to find an information that's not there or goes
to end of file, it'll naturally give NULL (or illegal) character
as its output, giving exception message.
Based on these facts, we can deduce (and was proven by opening
the custom computer braille table from KeyWord and examining its
structure) that the following might be happening:
1. When the user is creating first set of key bindings and
display patterns:
A. KeySoft uses default computer braille table for the language
(UK, Usa, etc.).
B. Because this default table (Unicode Tables file) would house
key combinations and "state" of key assignment for ALL characters
within the table, it'll be able to report that such and such
character has no keyboard bindings and is displayed as nothing.
C. The user adds some key bindings and display patterns. Then
the custom braille table will be created to house new entries.
2. In case user exits the Unicode Tables list without adding any
entries at all (for using it the first time in which default
entries will be enforced) or after assigning first set of
characters (by this time the custom table will be populated with
new entries), the user decides to exit. At this point, the
custom file would be saved.
3. When the user reenters unicode tables (by invoking unicode
entry command) to assign more characters:
A. This time, since KeySoft would be using customized computer
braille set, it'll open the cuminm table.
B. When the user attempts to assign key bindings (for entering
characters), it works as expected because the key combination is
already there within the custom table itself.
C. Suppose that the user wishes to add a display pattern to a
new character. This time, the exception message will be
displayed simply because KeySoft couldn't find anything at the
end of the file - found just NULL character (empty string).
Also, it is crucial to investigate the structure of the custom
braille table:
* The table is divided into three parts: key bindings for
lowercase table, key bindings for uppercase and display patterns.
* When you read the table, you'll notice that there are braille
combinations which only appears on the keymap (first two
categories) but not on the display sestion.
* The file ends with a blank line. This is important since this
would be the root cause of the exception message.
Therefore, I would like to present two solutions:
* Duplicating key bindings sections to the display sections so
that all possible eight dot display combinations are covered.
This would simplify the readability of the file and allows easy
manual assignment of display patterns provided that the user can
open the braille table and obtain Unicode character number.
However, it has a small cost of the table taking more space on
the disk, but with large storage area, I believe this is a minor
thing.
* Adding a "place marker" text at the end of the table file so
that KeySoft would know that there is a room availible for future
dot pattern assignments. However, we need to consider file text
manipulations, but current test results indicate that KeySoft is
good at managing entries located between entries. Also, it could
add to some unnecessary disk writes and reads, but with smarter
user entry checking (such as a possible error message when a user
attempts to unassign a display combination when the character is
displayed as nothing), this problem could be avoided.
Of these two possible solutions, I think the second option would
work well from programming perspective. Although first option
would be useful to cover all cases with advantage in less
information to manipulate, the second solution allows dynamic
resizing of custom tables and ensures that there would be at
least one more assignment of braille patterns for new characters
and would eliminate the exception message (for the time being),
as it is shown that the exception message goes away if a new
table entry is written at the end of the file (for one character
assignment only).
Thanks, and I hope this info was useful to BrailleNote user
community and to HW staff.
Sincerely,
Joseph Lee
University of California, Riverside
___
Replies to this message will go directly to the sender.
If your reply would be useful to the list, please send a
copy to the list as well.
To leave the BrailleNote list, send a blank message to
[email protected]
To view the list archives or change your preferences, visit
http://list.humanware.com/mailman/listinfo/braillenote
