[brailleblaster] Re: Some design considerations
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 8 Oct 2012 13:12:09 -0400
Chunking input files may be a workaround but will significantly
increase the complexity of the program when opening documents. We are
talking seconds of processing here, nothing unusual in the desktop
computing world. As for UTD, they seem to be the intermediate format
between the input and the final output, including when users want to
save their work and continue or re-use the file later. What would be
the official output format then, if users do not wish to save their
work in epub or nimas or some other standard?
F.
On Sun, Oct 7, 2012 at 10:56 PM, John J. Boyer
<john.boyer@xxxxxxxxxxxxxxxxx> wrote:
> Since BrailleBlaster will be showing both print and Braille when a file
> is opened, it seems best to pass all xml files through liblouisutdml to
> produce a utd file. This file will then be opened and processed by
> BrailleBlaster. The only problem is that there may be a few seconds
> before it becomes available. How can this be made less unpleasant for
> the user? Once the utd file is available it will be parsed bby the build
> method in xom. I think we should time this method for a large document
> to see how fast it really is. It seems to me that the slow performance
> is really due to the walkTree method and loading stuff into StyledText.
> Perhaps we can load only a few screenfulls at a time, and load more as
> the user scrolls.
>
> Of course, when a utd file is opened the translation step is skipped. I
> think that utd files should be referred to in the user interface as
> working files, without mentioning utd.
>
> John
>
> --
> 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: