Hi folks,
Yet another one of those summary posts and answers - I enjoyed
reading a few informative posts while studying for exams.
This message is divided into three parts: answers on recent
questions, explanation on platform differences and some opinions
on so-calledmp3 encoded recordings.
Few answers:
* For Kristen and others: When you email the actual 2010 document
to your instructors, do they see proper formatting? How about
saving it to 2003 doc and, without going through KeyMail, showing
it to your instructors? Have you read the actual word doc on your
BrailleNote to see if the formatting holds? If the answer to the
last question is yes, then its something that we need to
investigate further; if the answer is no, then its formatting
from Word.
As for PDF lines running together, sounds like markup problem
with displaying new line character. I heard some PDF producers
(programs which make PDF's) have compatibility issues when
generating PDF's that could cause problems with KeySoft.
* Memory problem under mPower: As Alex said, its not Flash Disk -
rather, its RAM Disk that is getting full (not in a physical
sense, but in a virtual sense). This famous problem exists with
models other than Apex - after browsing web for a while, you'll
get either: "not enough storage is availible to process this
command" (KeySoft 7.5 or earlier) or "virtual memory is under
certain percent" (KeySoft 8.0).
To illustrate this problem, consider a big box that can hold
about a hundred envelopes sitting on top of a chair, and there
are about six envelopes at the bottom. Suppose if you start a
task, a new envelope would be placed on top of the stack of
envelopes in the box. As you work on and on with your task, you
might need to work with larger files and documents, hence more
and more envelopes would be added to the box. However, in the
middle of the box (around a third way from bottom), there is a
yellow line drawn around the outside perimeter with the
instruction underneath, "you may put this many envelope be not
more. If you do, the chair that the box is sitting on will
break."
Now you start with six envelopes. Then you say to yourself,
"okay, I need to read a ten page file." When this happens, ten
envelopes would be placed on top of the stack, with the total of
16. Then you say, "my assistant is telling me I need to read a
huge document, but she didn't tell me how large it is. I'll try
to fit the documents as I read them, counting each page as I go
along." Hence you start reading the document, and as you go
along, more and more envelopes would fall into the box,
eventually getting close and close to the yellow limit line. But
then you notice that, as you put more and more envelopes, the
chair that the box is sitting on starts sinking lower to support
more weight. Eventually, you get very close to the yellow line
(with a lot of envelopes) that the chair starts breaking apart.
But then you say to yourself, "but I have a lot of room left on
my box; why did the box break when the limit was reached?" Then
you think, "aha! if I need to work on large files, I need to
start from scratch, and every time I get close to the limit, I
should tell my assistant to stop."
This whole scenario illustrates the lurking problem of Windows CE
5.0 and under (including mPower, which runs on top of CE 4.2):
even though you have a lot of RAM (physical memory where programs
run) to work with, because of the "limit line," you cannot use
all RAM. And this limit line turns out to be "virtual memory" -
and yes, the "yellow line" represents 32 MB virtual memory limit
iposed on all programs running under this OS (KeySoft included).
As programs use more and more virtual memory, naturally it'll run
out room to handle data, thus the warning.
Now let's imagine what happens if we have Apex: Same scenario as
before, but with a small twist; instead of approaching the limit
line, you run out of space to put more envelopes. But at least,
you don't have to worry about limiting yourself to small
documents - it can read large files, provided that you have
enough room in the "box" to hold these envelopes.
To end this discussion, the box represents RAM, the limit line in
the first scenario represents virtual memory, the chair
represents the computer and the envelopes represent data used in
RAM. The first scenario is applicable to Classic, PK and mPower,
while the latter is "theoretically" applicable to Apex (although
user tests shows that RAM would not fully be used).
Now onto the whole business of platforms, machines and what they
understand (geared towards techies):
All computers or computerized machines (notetakers included)
knows only two characters: 0 and 1. How do we actually use these
two letters to represent wide array of things such as braille
characters, types of USB device attached and so on is beyond the
scope of this list (more appropriate for programming list). But
it is essential to remember that a given computer knows its own
ways of understanding binary characters to do its job (called
machine language). Each CPU family from vendors such as Intel
and ARM know its own language, just as a person knows his or her
native language.
With that background in mind, suppose if Alex H wrote some games
for Intel processors. It'll work fine under Core series
processors from Intel because the processor can understand what's
going on and run the game. But if Alex wants to see these games
be used on his iPod Touch. Would it work out of the box? No,
simply because the processor used in iTouch doesn't know what it
is reading, so it cannot do things like, "draw a line". Rather,
the CPU in there (ARM) would say, "hey, I don't know what you're
talking about, so I'll just ignore you." Or it could try doing
something, but it could lead to wrong results - what if Alex told
the program to draw a line but the processor responds by deleting
a file? Catastrophic, right?
Another problem that complicates matters is the behavior of the
"ambassador" A.K.A. operating system. Different operating
systems (or, in our language, "middle man" or system programs)
has its own way of controlling hardware. For instance, the way
Mac controls a printer could be (and it certaintly is) different
than how a printer is treated under Windows. In some cases,
something that works on one OS may not work under another OS,
even though both were written to use the same CPU, or it could be
that the program format used on one OS might not be compatible
with another OS under same processor. This last statement is
true between regular Windows and Windows CE. And if different
OS's are designed for different machine languages, how could they
cooperate when it comes to running a progrkm written for one
system alone?
The below statement is an update to SDK seekers: there's actually
development environment that'll allow a program to be written and
compiled for Windows CE devices. What's missing are
documentation and tools from the manufacturer that describes
functions used to control BN's hardware through a program that
runs on the Apex, like what Sendero is doing now. In other
words, we have the necessary software to code our ideas and
necessary hardware to test and run them - what's missing are
descriptions on how to access the test hardware using code (and
this statement summarizes what's called "device-specific SDK"
under Windows CE).
Sorry for this long post - and my apologies again on hard words.
Hope you understand (if there are any comments, feel free to let
us know).
Cheers,
Joseph
___
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
