Hi All, Could anyone take a look at the following to see if it can be reproduced? I would be interested in what types of BN/VN it appears on. You need to be in Computer Braille for this. Only two out of the fifteen tests in the full problem are included for brevity.
Many thanks, Steve. Problem outline:- I first saw this on a 32 cell BrailleNote version 7.2 build 47, around May 2007, which was when it was initially raised with HumanWare. HW have struggled to see this problem, being able to reproduce it about a year ago, but no longer. The problem has persisted through 7.5, and is still there on 7.5 build 29 - (I am using the same machine as on 7.2). The tests detailed here were carried out on 7.5.29. I have included a file, (see page section "File contence"), that can be used to demonstrate the problem. In each of the tests, the included file was used as the original starting point. The reason why this is a "wrong results" problem as opposed to simply a "wrongly positioned cursor", (and therefore more significant), is that an incorrect character is deleted. Machine specifics:- Machine configuration: BrailleNote 7.5.29 BT32 transplant, hardware RVC6S, kernel version: 6. Aug 2 2007. Usual settings - (those used during the problem unless otherwise stated):- Under Braille options: computer Braille; UK table; eight dots; cursor both dots 7 and 8. Under Keyboard: computer Braille; uk. Braille grade within document: computer eight dots. Under review voice: speech Eloquence. Options on opening a document: Text format; translate to Braille no; open in paragraph format; save in paragraph format; extended ASCII character option retain; extended character set ANSI. Steps to reproduce the problem:- Initial preparation of the file: Block off all the text between the lines of equals in the section "File contence" and paste it into an empty ASCII file. Certain aspects of the file need to be exact. If you have a newline at the top of file, delete it - the first character should be a double quote. Next replace all newline characters, each one with a single space. Go to end of file, and if there are any trailing spaces delete them. Now add three newlines to the end of file, possition the cursor to top of file and exit. Edit session exhibiting this issue: Edit the file with the word processor, answering no to review options. (On entry the cursor should be at the top of file). Substitute "<space>1" with "<newline><newline>1" all occurrences. This places the cursor on the first newline of the string "<newline><newline>1:1-25" - (this string is then followed by a few more characters, including three newlines to end the file). Now move the cursor using the touch cursor to the first "1" of "1:1-25". Then use a backspace to delete one newline - this works as expected. Finally, backspace once more to delete another newline. This is the point where the problem occurs. The newline I expect to go, (the character between "(Jude" and "1:1-25 NAS95)"), remains. One of the three newline characters at the end of the file is deleted instead. (The cursor finishes on what is now the first newline after "NAS95)"). (In the above description, the symbol <space> represents one space character, and <newline> represents a single newline character. The newline can be generated either by <space> with dots two and six, or by using Unicode character 13). Tests and results:- 9. Equivalent of fuller problem description initial demonstration. Changes to the file before reproducing: none. Changes to edit session: none. Changes to usual settings: none. Results: reproduced. 15. American Braille. Changes to the file before reproducing: none. Changes to edit session: none. Changes to usual settings: set both Preferred English Braille code and computer Braille table, to USA, (under Braille options in the option menu). Results: reproduced. Further comments:- The following may be required during an edit session for the problem to occur. The edit needs to be done using Computer Braille. A substitution before the offending delete which includes a newline character in the replacement string. A specific number of characters between the last two substitutions. It might depend on how the end portion of the file is fitted on to the display. Other observations that might be useful:- The file must contain only three newline characters, all at the end. If the file contains other newlines, (which it can when transferred as part of the contence of an email), the problem does not reproduce. If there are only two newlines in the file at the end, during the edit session, when the tuch cursor is used just after the substitution to move to "1", it jumps instead to the last newline compromising the rest of the test. File contence:- ================================ "18 that they were saying to you, "In the last time there will be mockers, following after their own ungodly lusts." 19 These are the ones who cause divisions, worldly-minded, devoid of the Spirit. 20 But you, beloved, building yourselves up on your most holy faith, praying in the Holy Spirit, 21 keep yourselves in the love of God, waiting anxiously for the mercy of our Lord Jesus Christ to eternal life. 22 And have mercy on some, who are doubting; 23 save others, snatching them out of the fire; and on some have mercy with fear, hating even the garment polluted by the flesh. 24 Now to Him who is able to keep you from stumbling, and to make you stand in the presence of His glory blameless with great joy, 25 to the only God our Savior, through Jesus Christ our Lord, be glory, majesty, dominion and authority, before all time and now and forever. Amen." (Jude 1:1-25 NAS95) ================================ ---------------------------------------------------------- "seek ye first the kingdom of God, and his righteousness;" (Matthew 6:33 AV) ---------------------------------------------------------- _______________________________________________ BrailleNote mailing list [email protected] http://list.humanware.com/mailman/listinfo/braillenote
