[brailleblaster] Re: Latest News

  • From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
  • To: <brailleblaster@xxxxxxxxxxxxx>
  • Date: Mon, 6 Jun 2011 09:46:08 -0700

Hi Chris, interesting comments.  It would be good to keep word wrap for
braille.  If that means that word wrap is still needed for the text, wlel,
that would not be a disaster.  It will still be up to the user to keep
things in synch.

Word wrapping of the text will seldom be a problem, so maybe we should just
ignore it and leave word wrap on.  I see no problem with inserting many
pages of braille.  The "right" way to re-synchronize would be to just
retranslate and let liblouisutdml fix formatting.

John G

-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Chris von See
Sent: Monday, June 06, 2011 9:26 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Latest News 

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.
>
>
>




Other related posts: