[duxhelp] Re: Request for input on DBT installation
- From: "Peter Sullivan" <peter@xxxxxxxxxx>
- To: <duxhelp@xxxxxxxxxxxxx>
- Date: Thu, 22 Jul 2004 12:15:39 -0400
Lissa,
I also prefer to read braille in "ASCII" form. But the trouble is that
people worldwide have a different defintion of what that means. Try this:
with a braille document opened in DBT, select "Print Font" from the View
menu. Now, using the Global, Internationalization menu, change the braille
encoding (the lower setting). Ignore the warning message (which applies
only if you're viewing with braille or simbraille fonts) and behold the
results.
- peter
-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On
Behalf Of Melissa Hirshson
Sent: Thursday, July 22, 2004 9:55 AM
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: Request for input on DBT installation
This is very interesting. As a transcriber, I do not know how else braille
could be represented other than ascii characters, since that is how all word
processing is done. Even the Tiger embosser, which is trying to marry
graphics and braille, uses ascii when it comes to braille. When I need to
quickly dash off a simbraille printout for a signage customer, I just type
in the ascii characters directly into a blank Word file. Transcribing is, in
a sense, very, VERY glorified word processing--how else would we do it
without ascii?
You are right, of course, in that in an ideal world we could emboss braille
or New York Point or graphics all together without any difficulties. We just
have to make sure that the ability to function otherwise is not compromised.
We at National Braille Press look at ascii characters all day, every day.
That is mostly because we need to make corrections to files without
retranslating them. I'm sure this is the case for the other major braille
printing houses. I don't know how much braille the major houses produce
versus the smaller organizations, but even if we are a "tiny minority" of
people, we can't work any other way.
And the beat goes on. :)
Lissa
NBP
David Holladay wrote:
>This is a great idea. But it is a bit impractical. The problem is that
>virtually all of our users do not understand the concept of an encoding
>between ASCII and braille characters.
>
>In one sense, it is an obsolete concept. A truely modern embosser would
>allow an arbitrary use of the field of dots.
>If you want graphics, fine. If you want New York Point (2 dots high, 2,
>3, or 4 wide) fine. If you wanted to experiment with a 4 by 4 block
>that allowed perfec representation of a 16 bit Uni-code, fine. To do
>this would require the driving software to express raw dot patterns.
>
>But back to the task at hand. Braille transcribers who only look at dot
>patterns do not ever look at ASCII representations of braille. Many
>users do not closely examine the braille, they just output and give it
>to blind people for comment.
>
>So only a small minority want or need an ASCII representation. Of
>those, only a tiny number would have a problem if it was not exactly
>set the way they want it right out of the box, as long as we follow a
>protocol as I have suggested.
>
>Believe me, the DBT team has discussed asking users this question many
>times. Each time we conclude we will lose people if we try to explain it.
>
>-- David Holladay (with a tip of the hat to Peter, who dearly wishes
>all embossers could be addressed as strictly a field of dots)
>
>---------------------------
>
>
>
>
>At 08:18 AM 7/22/2004 -0400, you wrote:
>
>
>>Hello Dave:
>>
>>During the installation process, there could be a prompt that says
>>"Please choose the international braille table you want to use as the
>>display braille table when using the program. Please choose from the
>>list below:". You could ship the product with the North American
>>display as the default.
>>
>>You could then choose the language from a list box with the <UP> and
>><DOWN> arrow keys or you could make the selection by clicking with the
>>mouse.
>>
>>What do others think.
>>
>>Siincerely:
>>
>>Dave Durber
>>
>>On Tue, 20 Jul 2004 15:00:07 -0500, you wrote:
>>
>>
>>
>>>Hello, Testers;
>>>
>>>I need you opinion on an issue regarding what happens when DBT boots
>>>up for the first time.
>>>
>>>This involves the Global, Internationalization, Braille Code for
>>>Display
>>>
>>>Some background is necessary here.
>>>
>>>In DBT, if you are looking at a braille file in braille dot font, you
>>>see the actual dot pattern that will hopefully be embossed. If you
>>>are looking at a braille file with an inkprint font, things get more
interesting.
>>>
>>>In North America, we are used to seeing a full cell represented with
>>>an equal sign. Why? Because that is the way we do it, and all braille
>>>devices set for North American braille know that an equal sign means a
full cell.
>>>If you are using a braille display device with a screen review
>>>program, the screen review program looks at the equal sign on the
>>>screen and puts a full cell on the braille display.
>>>
>>>But in France, they prefer an accented e as the print representation
>>>of a full cell.
>>>
>>>DBT has several different tables. If you want to, you can experiment
>>>with them by selecting Global, Internationalization, Braille Code for
Display.
>>>Be sure to have a braille file, and select an inkprint font to view
>>>it (otherwise, nothing changes).
>>>
>>>-----------------------------------------
>>>
>>>Where things get interesting is that the French do not like the
>>>system as it is. Up till now, when you first boot up DBT, it defaults
>>>to North American. This does not bother Americans at all.
>>>But it is annoying to those who give tech support in France who have
>>>to keep telling people to go to Global, Internationalization, Braille
>>>Code for Display, and then choose "French"
>>>
>>>To deal with this, Pete has put in some code that says "If this is
>>>the first time this code is being used, and you are in France", set
>>>for French Braille Code for display.
>>>
>>>That is all well and good. But if someone were using a computer 100
>>>meters into Belgium, (and had told Windows that their nation was
>>>Belgium), then DBT would still default to North American because the
nation is not French.
>>>
>>>----------------------------------------
>>>
>>>I think it would be a good idea to extend Peter's idea. I offer a
proposal.
>>>If we can come to some agreement, then DBT can wake up more
>>>internationalized than before.
>>>
>>>----------------------------------------
>>>
>>>Step 1:
>>>
>>>If located in France, use French display code If located in Germany,
>>>use German display code If located in Spain, use Spanish display code
>>>If located in the UK, use the British display code
>>>
>>>Step 2:
>>>
>>>If located in Europe (i.e. the nation's telephone country code starts
>>>with
>>>3 or 4)
>>> and the language of interface is French, the use French display code
>>>and the language of interface is German, use the German display code
>>>and the language of interface is Spanish, use the Spanish display
>>>code ?? if the language of interface is English, do we use North
>>>American or Britich display code (the question is, does nayone
>>>outside of the UK ever use the British display code)
>>>
>>>Step 3:
>>>If located outside of Europe ...
>>>(I have no idea of anything but to default to North American) (I do
>>>not know if those in South America use North American settings or
>>>Spanish settings on their braille devices)
>>>
>>>Some of you may have noticed that DBT does not have any Italian
>>>tables for braille display. At this point, I do not have a valid
>>>table (defined as a unique, single ASCII character for every
>>>64 braille symbols; no braille symbols left out).
>>>I would welcome a valid Italian table.
>>>
>>>---------------------------------------------------------------------
>>>------
>>>
>>>Please respond to this. I would like to work this out quickly.
>>>
>>>-- David Holladay
>>>
>>>
>>>* * *
>>>* This message is via list duxhelp at freelists.org.
>>>* To unsubscribe, send a blank message with
>>>* unsubscribe
>>>* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
>>>* subscribe, unsubscribe, and set vacation mode and other
>>>subscription
>>>* options by visiting //www.freelists.org. The list archive
>>>* is also located there.
>>>* Duxbury Systems' web site is http://www.duxburysystems.com
>>>* * *
>>>
>>>
>>* * *
>>* This message is via list duxhelp at freelists.org.
>>* To unsubscribe, send a blank message with
>>* unsubscribe
>>* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
>>* subscribe, unsubscribe, and set vacation mode and other subscription
>>* options by visiting //www.freelists.org. The list archive
>>* is also located there.
>>* Duxbury Systems' web site is http://www.duxburysystems.com
>>* * *
>>
>>
>>
>* * *
>* This message is via list duxhelp at freelists.org.
>* To unsubscribe, send a blank message with
>* unsubscribe
>* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
>* subscribe, unsubscribe, and set vacation mode and other subscription
>* options by visiting //www.freelists.org. The list archive
>* is also located there.
>* Duxbury Systems' web site is http://www.duxburysystems.com
>* * *
>
>
>
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
Other related posts:
