As we now have over 1000 BRAILLE-EDIT customers, the time is right for us to increase our technical support staff. We could think of no better place to advertise for an experienced BRAILLE-EDIT user than here in the Newsletter. We have one opening for a full-time Technical Support staff position, to start here in Madison on or around January 1986. Technical support staff are responsible for answering technical inquiries on the phone and in writing from BRAILLE-EDIT users and owners of other RDC products; testing software and hardware products; troubleshooting interface problems; and preparing technical information and documentation for users. We need someone with a variety of skills, including: attention to details; problem-solving abilities; patience and excellent listening skills; concise written and verbal communication skills; demonstrated ability to learn quickly; calm under stress. Experience with BRAILLE-EDIT and other Apple software for blind computer users is very important. Experience with other computer systems, as well as ability to write newsletter articles and/or instructional materials are definite plusses.
Here at Raised Dot we can offer: variety and challenge; opportunity for learning and growth; some flexibility in working hours; health insurance; paid lunch and vacations; profit-sharing and pension plans; some help with relocation costs. $14,000-16,000 annually to start, based on experience. Long-term commitment expected. Blind or partially-sighted individuals are strongly encouraged to apply. Madison has a relatively low cost of living, an excellent mass transit system (RDC is on three bus lines), fairly grueling winters (not much snow but very cold) and is generally well known for its high quality of life.
Please submit a BRAILLE-EDIT data disk with your complete work history, any questions or concerns you may have, and cover letter addressing our above-stated needs by November 15, 1985. Anyone phoning about this position will be disqualified. Address your communications to:
The new BRAILLE-EDIT User's Guide contains a handy chart that lists the ASCII characters in alphabetical order with their computer braille equivalents. Due to sheer stupidity on my part, this chart is not on the braille Quick Reference Card. I'll be happy to send a braille copy of this chart to anyone who would like one. Please send me a postcard, and I'll send you one right away. Thanks for your patience!
BEX Version 1.0 is now in the hands of our testers. We've examined and re-examined our schedule and see absolutely no reason why BEX Verson 2.0 will be delayed. We are all excited about the many new features in the program. We will send a separate announcement detailing BEX's features and availability to all Newsletter subscribers, so check your mail boxes in November for more details.
One relatively little-known satellite of BEX is the math Braille program called NUMBERS. NUMBERS is basically BEX with a plus: in addition to the Grade 2 to print back-translator, there's a Nemeth code to print math back-translator. NUMBERS works best in conjunction with a VersaBraille or Cranmer Brailler. The user prepares material in braille, using any combination of literary Grade 2, Nemeth code, and computer braille. This braille material is processed through NUMBERS' souped-up back translator for output to a dot-matrix printer.
This output can contain text, hyper-complex fractions, square roots, integral signs, Greek letters, etc. NUMBERS is now being used by teachers and other professionals to prepare instructional material, and by high school students to prepare their homework. At present, NUMBERS supports two printers: the Apple Imagewriter and the IDS Paper Tiger 4606. The supported interface cards are the Apple Super Serial Card, the Apple 2c ports, and the Slotbuster.
If you're working with a lot of mathematical and scientific material, and are interested in being able to independently produce papers, tests, handouts and reports, communicate with the NUMBERS expert, Caryn Navy at 608-257-8833.
As related by Pete Rossi to Cub Reporter Becky Rundall
Apple Jack is an Apple Computer Club in Madison, New Jersey, whose membership includes kids and adults, professionals and non-professionals, professional kids and non-professional adults, hackers and neophytes. Their fundamental purpose in life is to share Apple information and resources and to have an instructive and enjoyable time doing so. They meet once a month for discussion and demonstrations of Apple-compatible software and equipment.
The reason everyone is saying such wonderful things about Apple Jack is that they are one of this year's big winners in the Apple Computer Club National Merit Competition. And what that means is that they've done some outstanding stuff with their Apples.
Earlier this year, Pete Rossi's demonstration to his fellow-Apple Jackians of the Echo speech synthesizer in conjunction with BRAILLE-EDIT, generated so much interest in braille production that several members volunteered to input textbooks for New Jersey's braille-reading students. And, as Pete points out, once these books are stored on disk, the copied master will be made available nationwide through the American Printing House for the Blind's Central Catalog.
At this writing, with two books under their belts, Pete thinks it's only a matter of time before these BRAILLE-EDIT "trainees" cut loose with BETTE. We're delighted and so are the Apple Computer Club people--they've awarded the Madison Apple Jack Club a plaque in recognition of Community Service, a knapsack with the AppleWorks logo (to be raffled off at an upcoming meeting), and (possibly) AppleWorks software.
So congratulations to the Madison Apple Jack folks--and a big thanks to Pete Rossi for introducing them to BRAILLE-EDIT and braille production.
[Just a little note about Pete himself. He works for the New Jersey Commission for the Blind and Visually Impaired, where he regularly uses BRAILLE-EDIT. One of his projects involves setting up Apple systems in all four regional offices and the Commission's Rehab Center. The New Jersey Commission has a wonderful goal--they intend to train all of their clerical and professional staff (we're talking over 100 people) to use BRAILLE-EDIT! And some of those people are sighted!]
The VersaBraille II is the new disk-based VersaBraille being sold by TSI. A number of people have been asking how to interface a VersaBraille II to the Apple. Please be aware that the VersaBraille and the VersaBraille II are VERY DIFFERENT MACHINES. Because the "old" VersaBraille is carefully supported by BRAILLE-EDIT, the interface between the regular VersaBraille and the Apple computer is extensively described in Raised Dot Computing literature. Until now, there has been no interfacing literature on the BRAILLE-EDIT to VersaBraille II link. While BRAILLE-EDIT does not support the sophisticated regular VersaBraille transfers for the new VersaBraille II, some existing BRAILLE-EDIT features make communication between the devices possible.
I have tested the interface with both an Apple Super Serial Card and a CCS 7710 card. Both work fine. The CCS card has four switches that set the baud rate. I recommend 9600 baud--Switches 1, 2, and 3 on, switch 4 off. The RDC Interface Guide recommends one combination of Super Serial Card switch settings as "the basic recipe." The "basic recipe" worked fine for the VersaBraille II interface: jumper block to "terminal", bank one to "off off off on off on off", bank two to "off off on on on off off." This sets the Super Serial Card to 9600 baud, 8 data bits, 2 stop bits, and no parity.
Use a straight through male-to-male cable. This cable is generally available at computer stores, or you can buy it for $35 from RDC as a "6M" cable.
To set the VersaBraille parameters, enter "P" for parameters, and "S" for serial. There is one very strange item in this list--you must specify 7 data bits. I admit I don't understand why you need to set the Super Serial Card to 8 data bits while the VersaBraille II is set to 7 data bits. Without a doubt this is the trickiest aspect of the interface. The other parameters are straightforward:
For most VersaBraille II applications, it is preferable to have the "VersaBraille Emulation" set to "on". If you wish to control the Apple with the VersaBraille keyboard, it's easiest from this mode. To get this "VersaBraille Emulation" mode: enter "P" for parameters, "C" for com mode, and "V" for VersaBraille emulation, then set the mode to "on."
On the Main Menu, option I - Input from slot allows you to import data from another computer cabled to the Apple. The "download section" of the BRAILLE-EDIT configuration questions asks: "Do you want to input information from a serial port?" Answer yes, and then specify the serial card slot number for the CCS or Super Serial Card that you will use for VersaBraille II communications. (On some, older versions of BRAILLE-EDIT, you will be asked if you have an end of file character. Answer "no" to that question.)
On BRAILLE-EDIT's Main Menu, choose "I" for Input from slot. You are prompted: NEW CHAPTER. After you give a chapter name, the Apple prompts START DEVICE. That means that the Apple is waiting for text to be sent to it.
Now, let's pay attention to the VersaBraille II. To send text to the Apple, enter "F" for files, "P" for print, and "S" for serial. You will be asked if you want to format text. Answer "yes". You will be asked for the device (internal, drive 1 or drive 2), and the file name. Finally, you will be asked if you want to pause. Answer "no". The file should be sent to the Apple. When the transmission is over, hit a "Q" on the Apple keyboard, and the new chapter will be saved to disk.
To send a file to the VersaBraille II, use the BRAILLE-EDIT print option. You must use one special format command to send clean files to the VersaBraille. Write a very short chapter on your program disk that contains these three characters: $$z. The "$$z" turns on "typeset dump mode"--none of your format commands are executed, and it overrides the carriage width and form length set up on the Apple. Whenever you want to send data to the VersaBraille II, print this short chapter first.
Of course, you also have to tell the VersaBraille to expect some text. If the file is under 10,000 characters, then keep VersaBraille emulation on. Otherwise, turn the VersaBraille emulation off. To tell the VersaBraille to accept a file, enter "F" for files, "P" for print, and "I" for serial in. Now use the BRAILLE-EDIT print option to send the file, making sure that your "$$z" chapter is printed first. When the transmission is over, enter a control-R on the VersaBraille II. The file will be saved under the name VERSABRAILLE SAVE. I urge you to rename the file so it will not get clobbered the next time you want to transfer a file.
If the VersaBraille emulation is off, then the procedure is slightly different. You will be asked for a file name and a device (internal, drive 1 or drive 2) before the transmission starts. You will also be asked the question "send commands?" Answer no by hitting any key other than "execute". Now start the printing on the Apple. When the transmission is over, enter a control-Z on the VersaBraille keyboard.
These instructions are just the bare bones to help a VersaBraille II user get started. I will be willing to assist any VersaBraille II user who is having problems with Apple communications. My phone number is (617) 986-6132.
The National Braille Association offers transcription services for college and adult-level materials. Working with BETTE, NBA can now produce their transcriptions on VersaBraille cassettes. All VersaBraille cassettes from the NBA cost $10 each. You may request transcription from inkprint, you may supply material on Apple 5-1/4" diskette, and you may choose from NBA's collection of college textbooks and general interest materials that are available on disk master. All these services are being established as field tests, and the National Braille Association will welcome any feedback as we assess the cost, quality and practicality of continuing service on a permanent basis.
Inquiries and requests for lists of available titles may be sent to
Do you use an Apple computer with an Echo speech synthesizer? Are you interested in learning more about programming? Do you like to play computer games? If the answer to any of these questions is yes, have we got a deal for you!
Apple Talk is a quarterly magazine for Apple computer users with speech synthesizers. Each issue contains TEXTALKER and APPLE TALK READER, the talking textfile reader software that enables computing novices to read Apple Talk's articles. Apple Talk will be published on Apple disks in February, May, August, and November of 1986. The magazine will include articles about programming; peeks, pokes, and calls; ads for computer products and software; EXEC tricks, games, and utility programs. Each issue will also contain resource materials as well as lists of recorded and brailled manuals and computer books. Apple Talk also maintains a disk library of public domain programs which work with speech output. These programs are available to Apple Talk subscribers for a $5 copying charge.
In order to keep the cost low, re-usable mailers are used to mail the disks, and the disk and mailer must be returned in order to receive the next issue. One year's subscription to Apple Talk for 1986 will cost $15.00. This price is good in the United States and Canada. Agencies and schools add $2 for invoicing. We will expect payment for all invoiced orders within 30 days. The rate for overseas subscriptions is $32 which allows the readers to keep all four disks and to receive the magazine airmail. All checks or money orders must be payable in U.S. funds and must be drawn on a U.S. bank. Make checks payable to Jeff Weiss and mail to:
We hoped that we'd be able to announce an Echo-compatible spell-checking program this month, but we can't. We've been in contact with Sensible Software, the company that makes one of the most comprehensive spell-checkers in the Apple universe, Sensible Speller.
Due to fundamental incompatibilities between BRAILLE-EDIT and Sensible Speller's proprietary, copy-protected operating system, it's not possible for a version of Sensible Speller to work directly with BRAILLE-EDIT chapters. But Sensible Speller currently works fine with textfiles, which BRAILLE-EDIT can easily generate. The hitch is getting access to Sensible Speller's screen output.
At last report, they were nearing completion of a ProDOS Sensible Speller that would work with the ProDOS TEXTALKER Version 3.1P. They have no timetable for a version of Sensible Speller that's compatible with DOS 3.3 TEXTALKER. While we can make no promises on what software that hasn't yet been written will cost, Sensible Speller IV, their current DOS 3.3 software, lists for $125. If you'd purchase a BRAILLE-EDIT and Echo-compatible spell checker, you might want to drop Sensible Software a note expressing your interest.
The Technical Services Unit of Kentucky's Department for the Blind is ready to release the construction manual for the Kentucky PortaBraille and Kentucky PocketBraille.
The PortaBraille is an interactive braille computer terminal with a 20-cell refreshable braille display, braillewriter keyboard and up to 56K of memory. Intended as a less expensive note-taking and writing system, the PocketBraille can be used as a "paperless braillewriter." Contents of its memory can be transmitted to a host computer and edited there. Plans are under development for equipping the PocketBraille with speech output.
The construction manual contains complete information for construction of either device, a full parts list, and a list of sources for obtaining parts.
Anyone requesting a manual should accompany the request with a check or money order for $5.00 (five dollars). These should be made payable to: Kentucky State Treasury - Department for the Blind.
The Lowry Speech Project is working on a non-profit project to provide guidelines to commercial software developers who express interest in making speech conversions of their existing programs. We are asking professionals in the visually handicapped and learning and reading disabled fields to pool information, and already have available 2 series on disk or in print for those who are interested. To obtain these textfiles, please send 2 blank disks in a stamped, self-addressed return-mail folder.
The Apple/Speech Related Resource Lists drafts being generated by the Lowry Speech Project are currently being reformatted and enhanced for publication in late October, 1985. The no-profit drafts are $10.00 for the two-sided Apple DOS disk textfiles version and $7.50 for the print copy. If you would like to be added to the list of "Helpful Individuals," please send us the information you would like to see included with your contact information on Apple disk (to be returned). Be specific about your ability to assist others by including a printed list of your areas of expertise, and DO expect to hear from new Apple users in particular. If you are already on our "Helpful Individuals" list or any of the other related lists, please let us know if you want your reported information changed or deleted.
Please note: we do NOT read braille and can handle most quickly any request or information sent in print or on returnable disk.
"Dipner Dots" is a BRAILLE-EDIT feature that enables the period character of a daisy wheel printer to produce draft-quality braille. I have been able to produce usable braille on the Qume Letterpro 20 printer. This printer had several things to recommend it to us when we were buying. For one thing, it was in stock then and there: as you may have discovered, when you're out to buy a new offering to the great god Peripheral, you don't often want to wait if you can avoid it. More important (if anything can be more important than buying devices to feed the great god Peripheral,) the printer offered a choice of tractor- or cutsheet-feed and a wide range of typestyles. A very pleasant discovery was that most Qume-compatible daisy wheels have brass periods, which makes them well-suited for producing Dipner Dots braille. An equally pleasant discovery was that the undesirable linefeed functions (auto linefeed and carriage-return linefeed) can be turned off from the keyboard by using escape sequences, avoiding tampering around with the ill-placed DIP switches.
Producing Dipner Dots with this printer is an easy matter. One must remove the ribbon and wrap a write-protect tab around the sensor to fool the printer into thinking there is still a ribbon there; set the hammer-strike switch to "hard," and print a setup chapter which changes the undesirable DIP switch settings.
To date, we are just using single sheets with this printer, which makes the procedure a bit awkward. I have a double thickness of rubber sheeting which I have to line up with the paper, and this whole bundle must be rolled into the printer. Occasionally, it surprises me by going in straight! In addition, I haven't mastered the delicate art of replacing the ribbon cartriage, so someone else has to do that when ink-print is desired.
After considerable experimentation, I have found that fifteen pitch is satisfactory for me. This yields a wonderful 31-line, 38-cell-per-line product on a sheet of 8-1/2 by 11 bond paper.
I would be happy to send well-packaged samples of this braille to anyone wondering if it might be suitable, and to answer any questions my meager knowledge allows.
[Editor's Note: When considering buying a printer to use for Dipner Dots, there are three things to keep in mind:
If you are in a computer store and uncertain about the suitability of a particular printer, you can give us a call. While we don't know the details of every printer manufactured, we should be able to query the computer store salesperson using magic jargon, as befits the great god Peripheral.
In today's mail I received immediate feedback with very careful, complete explanation to a question about BETTE that I had sent to RDC along with a disk illustrating my problem. This moves me to express public appreciation to David, Caryn, and crew for one of the features I hear mentioned most often as I move about the country talking to users of electronic braille.
"The user support from Raised Dot Computing is fantastic!"
This theme with variations comes from all over. It is music to your ears and also to those of us who know we will get results when we write or call. Thanks!
That is my first reason for writing. The second reason is that I have seen nothing in the Newsletter about BETTE, your program written specifically to assist transcribers, since the May issue. I am calling this little article BETTE-WORKS (because it does) and suggesting that others who use BETTE make this into a regular feature by jotting a few notes to RDC with suggestions, helpful hints, or answered questions. We transcribers are in the minority of BRAILLE-EDIT users, so we need a corner of the Newsletter that will apply to us.
Here is the answer to my question. It is simple, but I do not find it in the manual. I consider the grade 2 translation provided in BETTE to be very, very good. As I find words that do not translate correctly (very few), I keep a list. When I went to add them to the FINETUNE chapter I noticed that chapter ended with 2 carriage returns --<CR>s--instead of the single <CR> that appears between each item as a termination character. I removed the extra <CR> before adding my list. That was correct. What I did not know is that the extra <CR> is necessary at the end of the chapter.
So to users of BETTE: 1. Do not hesitate to add to the FINETUNE chapter. 2. Remove the extra <CR> at the end of the present chapter AND add it to the end of the chapter after you finish adding material.
[Editor's note: You're right, Bettye, we never mentioned this in the BETTE Manual. The reason you need two <CR>s at the end of the FINETUNE chapter is that, for this transformation chapter, the <CR> is the "terminator." Global Replace recognizes the end of any transformation chapter when it encounters the terminator character at the "from string" position. All transformation chapters must end with at least two terminators. JK]
If your text represents mixed fractions as 1-1/2 (with a hyphen between the whole number and the fraction) the translator handles it correctly. But when the text shows mixed fractions without the hyphen as 1 1/2, the translator assumes that the fraction is also a complete number and it precedes it with a number sign. To avoid this problem, simply make sure every mixed number contains a hyphen between the whole number and the fraction as you enter it.
As many of you know, I am a constant user of the ED-IT program. [Aside: people now ask if BETTE was named for me. The answer is no, but ED-IT was named for my husband, Ed.] As a regular user of ED-IT, it should be known that I make good use of BETTE and that I do this with keyboard entry rather than braille entry. My reason for telling you this is that I wonder if teachers who have BRAILLE-EDIT available for use by visually impaired students, realize BETTE's potential. This addition to their program makes it extremely easy to type in teacher-handout sheets, additional information, notes to the student, and other materials that are not necessarily textbooks.
BETTE is not suitable for braille requiring spatial presentation, such as math or music code (my specialty). [Editor's Note: Indeed Bettye is world-reknowned for her work with music braille. JK] However, I love it for text material. I find that I can catch braille errors more quickly by using the Print option with SH (ASCII on the screen) than with SB (braille on the screen) because the alphabetic characters stand out from the contractions so clearly. It really doesn't take long to get used to what the contractions look like in ASCII. When I run into something such as columns that cannot be handled by BETTE (which sometimes happens in the specialized material about music that I am brailling for NLS), I still enter the text portion from the regular keyboard, translate it, and finetune it. Then I take the grade 2 chapter and write it to a textfile to transfer the data into ED-IT format. While ED-IT is more appropriate for line-oriented brailling, I recommend BETTE very highly.
Do you realize the far reaching effect BETTE, BRAILLE-EDIT and its translation features can and will have on the availability of braille materials for the blind reader? Being primarily concerned with educational materials, it is a tool welcomed with open arms. Certified braillists willing to tackle the chore of textbook transcriptions are overworked and underpaid. In this situation, "underpaid" denotes NO remuneration--the majority are strictly volunteers. Here we are sitting in a very tiny but unique corner of the world where we spend hours on end producing combinations of dot patterns which must be free of any mis-positions. The multiplicity of reference books that lay out the proper design of formatting according to the subject matter can easily bewilder the timid.
The advantages computer technology has offered the braillist cannot be too loudly applauded. But, a computer offers no advantage without viable programs that can be used and understood by the busy volunteer. The diversity of BRAILLE-EDIT, and its satellites such as BETTE, is causing the retirement of several of my other programs. Here is the word processor by which my correspondence, articles, etc. are produced. Often these same pieces are required or desired in a braille edition. Same program, same input--two versions! Mistranslations are the exception rather than the rule. Once the mistranslation is identified, it is corrected in the FINETUNE chapter, never to be wrong again.
Voila! Enter the non-braille knowledgeable typist! Under the supervision of the braillist who can either pre-structure the text for the typist or who can insert the formatting commands after input, many more students will be reading tactually what has been available only auditorily. Braillists have been longing for help with assignments. Now the promise of help has become a reality. No research is needed to ascertain that there are more typists than braillists who have access to Apple computers. What we must now do is interest these typists in our production problems and then introduce them to BRAILLE-EDIT, BETTE and other programs. First of all, THANK YOU, RDC, for making all this possible.
[Editor's Note: Thank you, Conchita Gilbertson, for helping us to understand the needs of braille transcribers in general and the demands of VersaBraille transcription in particular. For those unfamiliar with Conchita's work, she has pioneered the use of computers in braille production through many years' association with the Instructional Media Resource Center in Virginia. Now on her own, she's available for consulting and training in computerized braille production. She's familiar with and provides instruction in using all the software available to braillists, not just ours'. JK]
To produce this Large Print Newsletter, I've had to work with textfiles a lot. Since they are very handy for many applications, and since BRAILLE-EDIT's textfile-handling abilities have recently been improved, I wanted to let readers know of the possibilities. Please note that all the features I describe here are only available on the July 22, 1985 Version 2.50 BRAILLE-EDIT disk.
BRAILLE-EDIT operates in the computer environment called "Apple DOS 3.3." DOS 3.3 controls how information moves between the computer and the user, in particular, how characters are read from and written to disk. Within DOS 3.3, there are four ways of saving information on disk--four "file types." Each type of file has its uses, and is identifiable by the letter in the first column of a full disk catalog. (You can get a "full" catalog two ways: hit the space after a BRAILLE-EDIT catalog, or type CATALOG at the BASIC prompt.) Three of these types appear on your BRAILLE-EDIT disk: Applesoft files, Binary files, and Textfiles. (The fourth file type is an Integer BASIC program file. Integer BASIC is a different dialect that BRAILLE-EDIT never uses.)
Applesoft files contain Applesoft BASIC programs. You can LOAD, RUN, SAVE, and LIST type A files. While you can include text in a BASIC program, it's not very efficient. An example of the kind of text that a BRAILLE-EDIT Applesoft file contains is the message: "MAIN MENU, ENTER COMMAND." One Applesoft file on the boot side of the BRAILLE-EDIT disk is called "SETCON". This file contains the Applesoft program that allows you to define a new configuration.
On the main side of the BRAILLE-EDIT disk, there's a Textfile named "XYZ". This file contains the list of options available on the Main Menu. Including extensive text in an Applesoft BASIC program is a pain, so we store this data in a textfile. When you hit <CR> at the "Main Menu, Enter Command" prompt, the contents of textfile "XYZ" are displayed.
Binary files store information for use by application programs: type B files can contain either programs or data, and your BRAILLE-EDIT disk contains samples of both. On the boot side, for example, there's a type B file named "FID". This contains the File Developer program. You can BLOAD, BRUN or BSAVE type B files, but you can't LIST them. There are also 4 binary files named: "RECENT CHANGES", "RECENT CHANGES.A", "RECENT CHANGES.B", and "RECENT CHANGES.C". Altogether, these four binary files comprise the BRAILLE-EDIT chapter named "RECENT CHANGES", which contains text describing the new features on the July 22, 1985 BRAILLE-EDIT disk.
You don't need a word processing program to use textfiles. In fact, all you need is Apple's DOS 3.3. Commands to create, read and modify textfiles are built in to this operating system. This has two consequences: almost any program based on DOS 3.3 will be able to handle textfiles, and, if a program is lacking this facility, a fairly new programmer can incorporate textfile-handling into the program.
But there are some disadvantages to storing data in textfiles, and that's why BEX stores data in binary files. One big minus is speed. While DOS 3.3 has textfile-related commands built-in, they're very slow. The other minus relates to a textfile's structure: it's basically one long string of characters. Imagine a textfile containing 8000 characters. If you decide to delete 200 characters somewhere in the middle, then you have to rewrite all of the characters after the deleted ones--and this process is doubly slow.
On the other hand, when you write BRAILLE-EDIT chapters, each BRAILLE-EDIT page is stored as one binary file. BRAILLE-EDIT adds two characters to your chapter name to make the binary filename. Every BRAILLE-EDIT chapter also has one binary file, around 3 sectors big, with the same name as the chapter name--that's the "directory" file that serves as the internal table of contents for the chapter. Since each BRAILLE-EDIT page is one file, it's easy to swap pages around. You only have to change the information in that chapter's "directory" file. If you were working with a textfile, you would have to rewrite all the data to disk. Two options on the Second menu, Read textfile to chapter and Write chapter to textfile, allow you to pass data back and forth between the two file types.
In addition to BRAILLE-EDIT, many other application programs can read and write textfiles, so it's a handy way to transfer data between programs. You can also use certain format commands to make the BRAILLE-EDIT process of writing textfiles exactly like printing. Then, you can read this "printed" textfile back to a BEX chapter to know exactly what the printed page will look like.
When you choose option W - Write textfile on the Second Menu, BEX uses default values to format your text. These defaults are different from the defaults for printing to the screen or a printer.
For paragraphs, the default values are $$i5 $$s2. Every ( $p ) indicator in your chapter wll be executed with an indent of 5 spaces and 2 <CR>s in your textfile. If you want to have 3 <CR>s and no indented spaces in your textfile, then use the format commands $$s3 $$i0 at the start of your chapter.
For line spacing, the default value is $$l0. This suppresses any <CR>s at the end of a line. It doesn't matter how that <CR> is created: it could be a <CR> or ( $l ) indicator that you typed, or it could be a <CR> that BRAILLE-EDIT automatically generates because you've exceeded the carriage width. If you want to enable <CR>s at the end of each line, use the format command $$l1 at the start of your chapter.
The default carriage width is $$w40, which doesn't affect anything if you accept the default line spacing of $$l0. If you do allow <CR>s at the end of each line, then $$w40 means that BRAILLE-EDIT automatically inserts a <CR> when the next word won't fit in before hitting 40 characters.
The default form length is $$f0. The zero form length suppresses any page-oriented commands, like page numbering, running heads, or form feeds.
Because of the way BRAILLE-EDIT underlines text, you may wish to omit all or $$h commands from a chapter you write to textfile. When the underlining is executed in a textfile, the result is: (letter) (control-H) (underbar) (letter) (control-H) (underbar) etc.
You can enter the "reset to default" format command $$d, to re-establish these defaults: $$f0 $$w40 $$l0 $$s2 $$i5.
To produce this Newsletter, I have to create appropriately-formatted textfiles. I then use a program called Mac.Transfer, which moves DOS 3.3 textfiles over a cable to Macintosh-format textfiles. PageMaker, the application program on the Macintosh that makes these lovely letters, doesn't have anything like BRAILLE-EDIT's Global Replace, so it's crucial that <CR>s only appear where they are really necessary. I want one <CR> to show up between paragraphs, and I need a <CR> on each line for lists, like the VersaBraille II parameters in Gayle's article. Paragraphs are easy: I insert $$s1 at the start of my chapters. Whenever I start a list, I enter $$l1. Then I can just type <CR>s when I need them and they'll be executed in the textfile. At the end of the list, I enter $$l0, and <CR>s are suppressed again. That way PageMaker gets the opportunity to break lines as needed. I leave the form length at the zero default, because I don't want any page-oriented information in my textfiles.
As a general rule-of-thumb, you want to minimize <CR>s at the end of every line if the program you're sending to is smart enough to break text into lines itself.
Other applications require different approaches. When you prepare information for a database program, you usually want one <CR> between each field in a record. When writing Applesoft BASIC programs you definitely don't want BRAILLE-EDIT to automatically generate <CR>s every 40 characters. Use $$w240 to set the carriage width to the maximum number of characters allowed in an Applesoft BASIC line. Use $$l1 to insure that the <CR>s you enter appear in the textfile.
For blind users without a hardcopy braille output device, "printing" to a textfile is a good way to proofread format. At the start of your chapter, establish the form length, carriage width, line spacing, line skip and indent at paragraphs with the appropriate format commands. It's important to establish the form length first, and if you want to see any page-oriented commands, your form length must be 4 or greater. Then, you can establish any other format commands you want: running heads, tabs, margins, outdenting, etc. Write your chapters to a textfile, then read the textfile back to a chapter. Review this chapter to see exactly where all the <CR>s and spaces will be in your final output. A new page is shown by the control-L character in your text.
Sometimes you don't want any format commands executed in your textfile. A good example is when you're using a spell-checker program. You write a textfile and then let the spell-checker make changes in that. Then you want to read the improved textfile back to a BRAILLE-EDIT chapter. This is where the "typeset dump" format command $$z comes in handy. Insert this command at the start of your chapter, and all BRAILLE-EDIT's format commands become lifeless dolllar signs, letters and numbers in your text. <CR>s that you type in your text will still appear, however.
BRAILLE-EDIT's option R - Read textfile to chapter can cope with situations that some other textfile-reading programs can't. The hardest part is finding the textfile's filename, since textfiles aren't listed when you press D for a disk catalog. When you're at the Second menu, press Q for Quit. Now you can depress your caps lock and type: CATALOG,D2 <CR>. Note the "T" in the first column of the catalog which identifies the file type as "text." Now type RUN, choose R, and follow the prompts. Make sure you use a different name for the BRAILLE-EDIT chapter you're creating.
When you examine this new chapter, don't expect to see any formatting commands in it! Usually, there are just tons of <CR>s and spaces. We've supplied a transformation chapter named "TXVB" on the main side of the BRAILLE-EDIT disk. Use Global Replace and TXVB to transform this mass of <CR>s into a more familiar BRAILLE-EDIT format. TXVB is designed to make acceptable VersaBraille format, so it seeks out underlining and replaces it with the underbar character. The grade 2 translator changes the underbar into the italics symbol.
Because textfiles store information in a fairly standard pattern, you can use textfiles as a trade language for moving data between programs. We've tried to make BRAILLE-EDIT write very correct textfiles, but sometimes another application program may rebel at reading them. Often, this rebellion is traceable to weaknesses in the other software's read textfile features. In particular, some programs need textfiles with frequent <CR>s--at least one <CR> every 250 characters. BRAILLE-EDIT's default values for writing textfiles only place <CR>s at paragraph ( $p ) indicators, but it's easy to change that default by using the $$l1 command. Some communication programs won't let you transmit many control characters, so control characters that are really there in the textfile BRAILLE-EDIT wrote seem to disappear. Truly crude textfile reader software may crash if your textfile contains commas or semi-colons.