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
