[brailleblaster] Re: Latest News
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 6 Jun 2011 14:07:32 -0500
Chris,
The tdml files (extension utd) are a single data store for each
document. An original document might come in a vairity of formats, such
as Daisy xml, text, Word, rich text, etc. Since the native format of
BrailleBlaster is UTDML, non-daisy files are first converted to Daisy,
then presented on the print view. When they are translated to braille
liblouisutdml adds the UTDML markup. The resulting file is then read
back by Brailleblaster and shown as the combined Daisy and Braille
Views. If a document is short it might be processed entirely in memory
instead of creating a file. In any case, when the user saves a document
it is saved as a UTDML file, with the extension utd.
I guess the UTDML parts of a file are the authorative version. The
original print text is just the starting pThe user can edit it and it
will be saved along with the braille, if translation has been done.
John
On Mon, Jun 06, 2011 at 11:33:30AM -0700, Chris von See wrote:
> Hi John -
>
> Some comments below.
>
> Like Susan, I think that I'm getting confused about how this is going
> to work. I'm also confused about which version of the content (text
> or braille) is considered authoritative... or is there a single
> backing data store that is used to build both displays and which is
> the data that gets saved when a user saves their work?
>
> Cheers
> Chris
>
> On Jun 6, 2011, at 11:09 AM, John J. Boyer wrote:
>
> >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.
>
> CvS: I'm glad to hear that translation and formatting are done based
> on paragraphs, headings, etc.. Since this is the case, you'll most
> definitely have cases where there is more than one braille line per
> paragraph, and so in order to implement synchronized scrolling you'll
> need to draw some relationship between the text and the braille so
> that as each line of a text paragraph is drawn to the top of the text
> view the corresponding braille line(s) can also be placed at the top
> of the braille view.
>
> >
> >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.
>
> CvS: I would think you'll also need to have a text-to-braille
> relationship of some sort (placeholders?) so you can tell where
> inserted braille text goes in the context of the text file and handle
> that appropriately when you re-translate. Here's a use case where
> this might be needed:
>
> 1) User enters text in text view.
> 2) User translates text to braille.
> 3) User enters transcriber's note or makes some other modification in
> braille view.
> 4) User modifies text in text view.
> 5) User translates text to braille.
>
> In this case there's no back-translation, but since the TN or
> modification was created you need to track it as "locked text" or some
> other sort of placeholder so that you can maintain its position
> relative to the text around it. You also need to be able to save and
> re-load that braille content from a file...
>
>
>
>
--
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:
