[brailleblaster] Re: Next steps
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 12 Jul 2013 14:11:27 -0500
The algorithm for the table of contents in utd needs to be in liblouis
so it is available outside BrailleBlaster. It's been on my list for a
long time.
John
On Fri, Jul 12, 2013 at 06:41:11PM +0000, Keith Creasy wrote:
> 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
>
>
--
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:
