[brailleblaster] Re: Latest News
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 6 Jun 2011 13:09:29 -0500
Chris,
Let me clarify. There is no correspondence between braille lines and the
lines in the print text. Translation and formatting are not done
line-by-line byt by paragraphs, headers and other logical items. When a
file is translated liblouisutdml produces information that enables
BrailleBlaster to know which print characters
correspond to each braille line. This is what is displayed in the Daisy
view after translation. The lines in the original text are ignored.
I'm really tickled that your wife is using MegaDots for Braille
transcription. I was one of the development team, responsible for math
translation.
If a user types material in the Braille view that does not exist in the
original text back-translation should not be attempted, because the
reason she added the materialin braille may well be because she doesn't
trust the translation. The material will appear in the utdml file, but
there will be no corresponding print text. The original print text, with
any edits that have been made, will of course appear in the utdml file
also. In cases where there are Braille lines with no print equivalent,
the braille view will display them normally, but the Daisy view should
have something indicating that there is no print equivalent. I don't
know what this should be. maybe some sort of icon with a descriptive
text for each line.
John
On Mon, Jun 06, 2011 at 10:10:10AM -0700, Chris von See wrote:
> Hi John -
>
> I think that any time a text line exceeds the line length for the
> required braille paper size you will need to create and display
> multiple braille lines for that text line. Otherwise, you get into a
> mess where you have to break each text line into whatever number of
> characters will fit on a braille line based on the page size and
> braille grade, not based on the display and font sizes, and you'll
> need to re-size every line in the file any time the user changes
> braille grade or paper, or any time a text line is forced to exceed
> the maximum due to user input.
>
> If a user inserts braille text into a line that does not exist in the
> text file (a transcriber's note, for example) it's quite possible that
> that text will be more than one braille line.
>
>
> Cheers
> Chris
>
> On Jun 6, 2011, at 9:51 AM, John J. Boyer wrote:
>
> >Chris,
> >
> >You have some good points. See my reply to the previous message for
> >some
> >clarification.
> >
> >Inserting blank lines to keep the two views synchronized will cause
> >extra complications and will probably generate bugs and user
> >dissatisfaction. It would be much better to enable the user to unlock
> >scrolling, then lock it again. This is actually simpler than dealing
> >with blank lines that are inserted just to keep the two views lined
> >up.
> >
> >As I stated, After translation the Daisy view will show the print
> >corresponding to each line of Braille. It will not show multiple
> >braille
> >lines for a print line. Word wrap should be turned on. That is what
> >people expect. They also expect to be able to turn it off. We will
> >have
> >to give them a means for doing so. This will not be hard.
> >
> >John B.
> >
> >On Mon, Jun 06, 2011 at 09:26:16AM -0700, Chris von See wrote:
> >>Hi John G -
> >>
> >>Thanks for your comments.
> >>
> >>I didn't realize that word wrap would be turned off on translated
> >>content. I'm not a transcriber, but I would think that requiring a
> >>user to scroll horizontally in order to see the entire braille line
> >>would be very inconvenient - it's certainly a pain in a normal text
> >>editor. This situation may happen fairly often - even if the user
> >>has
> >>their braille font sized to a more "normal" size - since braille
> >>cells
> >>are so much wider than their text counterparts, and especially if the
> >>user is translating to grade 1 braille.
> >>
> >>If a user adds additional lines solely for the purpose of keeping
> >>views synchronized, what happens to those lines when a user embosses?
> >>How does the tool distinguish a blank line that was added for visual
> >>reasons from a blank line added because of braille formatting rules?
> >>
> >>I think there is at least one case where turning off synchronized
> >>scrolling (or allowing for some sort of re-synchronization) would be
> >>appropriate - to allow a transcriber to insert content (braille or
> >>text) that exceeds the visible size of the StyledText control. If
> >>I'm
> >>adding braille preliminary pages, for example, that content may or
> >>may
> >>not appear in the text but will almost certainly exceed the size of
> >>the braille control's visible area (p-pages can run anywhere from
> >>five
> >>to 100 braille pages depending on the book).
> >>
> >>
> >>Cheers
> >>Chris
> >>
> >>
> >>On Jun 6, 2011, at 8:54 AM, John Gardner wrote:
> >>
> >>>Hi Chris. Below I put my interpretations of what the specs are or
> >>>maybe
> >>>what they are supposed to be.
> >>>John G
> >>>-----Original Message-----
> >>>From: brailleblaster-bounce@xxxxxxxxxxxxx
> >>>[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Chris von
> >>>See
> >>>Sent: Monday, June 06, 2011 8:38 AM
> >>>To: brailleblaster@xxxxxxxxxxxxx
> >>>Subject: [brailleblaster] Re: Latest News
> >>>
> >>>I have a couple of questions on scrolling two StyledText controls
> >>>together:
> >>>
> >>>If a line of text translates into more than one line of braille
> >>>JAG: This cannot happen. Word wrap is removed once the text window
> >>>shows
> >>>the translation, so the line may go off the page, but it doesn't
> >>>wrap to
> >>>another line. Unless a user is using a huge font, this should never
> >>>happen
> >>>anyhow.
> >>>
> >>>
> >>>or if
> >>>the user edits the braille to insert preliminary pages,
> >>>transcriber's
> >>>notes or other additional content that doesn't appear in the text,
> >>>how
> >>>will the scrolling controls behave?
> >>>JAG: If a user adds lines or otherwise changes the line formatting,
> >>>well I
> >>>presume that the two views will continue to scroll, but the lines
> >>>will be
> >>>mismatched below the point where this occurs. A user can put
> >>>additional
> >>>lines into both views to keep things synchronized, but she has to do
> >>>it.
> >>>
> >>>Is the scrolling line-by-line
> >>>based on the lines as seen by the StyledText control, will the
> >>>synchronization between the two controls be based on whatever
> >>>content
> >>>appears at the top of each control,
> >>>JAG: Yes
> >>>
> >>>or will you use another strategy?
> >>>and will end users be able to "un-synchronize" the two StyledText
> >>>controls so that they can be scrolled independently?
> >>>JAG: No, the user cannot turn off synchronized scrolling. I see no
> >>>overwhelming reason that someone would want to do it. So KISS.
> >>>
> >>>
> >>>
> >>
> >
> >--
> >John J. Boyer; President, Chief Software Developer
> >Abilitiessoft, Inc.
> >http://www.abilitiessoft.com
> >Madison, Wisconsin USA
> >Developing software for people with disabilities
> >
> >
>
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
