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
