[brailleblaster] Re: Next steps
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 12 Jul 2013 18:41:11 +0000
OK. It is probably the second or third thing people are going to ask about
around here. We could possibly address this on the Java side, perhaps even
dynamically. It is fourth on my list anyhow which probably puts it seveeral
months down the road. When I say "next steps" I'm probably talking about over
the next quarter.
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
Sent: Friday, July 12, 2013 2:12 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Next steps
Currently a table of contents is generated only if "formatFor textDevice"
Generating one for utd will require a different algorithm.
That has been postponed until the current code is working properly. It will
also involve dividing a book into volumes. If you use the current TOC it will
have to go into a text node, and it will have newline characters.
John
On Fri, Jul 12, 2013 at 05:58:04PM +0000, Keith Creasy wrote:
> All.
>
> I am anxious to hear what others think but let me share what I believe our
> next big step in development should be. Right now it is easy to open an XML
> file and one can even edit the content in the text view. Some important
> things that one can't do yet are:
>
> 1. Start a new document and immediately begin adding content. You can
> actually enter text into the text view now but it isn't being added in a
> valid way to the XML and you do not get any braille. We need to finish out
> the code that creates a new document and adds at least one text element where
> a user can enter new text, get braille, and save it back to a valid UTD XML
> document.
>
>
> 2. One cannot yet add braille to an existing document. One of the first
> things we are going to encounter, and we'll soon know if I'm right, is that
> users are going to want to add braille-specific information to the document.
> Transcriber's notes, acknowledgements, braille publication info, and such.
>
> 3. Related to the previous point, users are going to want to make corrections
> to the braille without effecting the print and even make corrections that
> can't be made in the print.
>
> 4. Table of Contents needs to be implemented. For the sake of simplicity and
> to speed this up I'd like to propose that we use the current LibLouisUTDML
> way of generating a braille TOC. Users would just move to the place in the
> document, perhaps in the tree view, and select that as the location of the
> TOC. A locked braille element would then be added with the braille TOC
> generated using the headings. I don't think this is going to be 100% reliable
> in the long term but it might work better than I expect and there's no reason
> to make it more complicated until we know.
>
>
> Regards,
> Keith
>
--
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:
