[brailleblaster] Re: Latest News
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 6 Jun 2011 15:43:29 -0500
Chris,
Your understanding of UTDML is correct. It can be generated for html and
text files as well as Daisy, but BrailleBlaster uses only Daisy. I have
a document that describes it wih examples. Icould send that to the list
if there is interest. it does nood more explanatory material, but it is
a start.
John
On Mon, Jun 06, 2011 at 12:21:31PM -0700, Chris von See wrote:
> John -
>
> Thanks for the explanation. So, if I understand this correctly,
> there's an authoritative UTDML backing store that is used to create
> both the text and braille views, and any edits made in either view are
> also immediately made to the backing store. I don't know what UTDML
> looks like, but from what you've said it sounds like essentially the
> same thing as DAISY but with additional tags added to contain the non-
> DAISY parts of the document (native braille content, tactile graphic
> info, etc.) - is that correct? If so, then it makes sense that the
> UTDML backing store would be the place for all the relationships
> between the text and the braille to exist.
>
> Cheers
> Chris
>
>
>
> On Jun 6, 2011, at 12:07 PM, John J. Boyer wrote:
>
> >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
> >
> >
>
--
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: