Yes I agree regarding XML being good when one needs to structure information. One big weakness is its verbosity, for that reason I like JSON for some uses. I haven't actually looked into using JSON in Java, I imagine there must be support for it. However I don't think JSON has anything which would compare with XPath for finding specific nodes.
Michael Whapples On 03/10/2012 13:07, François Ouellette wrote:
Looks like a good plan. My only comment would be the use of "properties files", to my view it would be better to use XML files, which would have a lot more flexibility in defining structures and dependencies between parameters, especially if we need to create a model of a document with headers, paragraphs, etc. I can imagine the difficulties in creating properties names and values to describe heading levels, paragraph spacing, etc. The document model in XML would also be a lot more detailed as a support to the editing functions than properties. XML structures can be searched with XPath, whereas java properties require loops to scan a list of text values. All modern text editors use XML as a support and storage technology. Java properties were designed to keep key-value pairs only. My 2 cents. F. On Tue, Oct 2, 2012 at 11:21 PM, John J. Boyer <john.boyer@xxxxxxxxxxxxxxxxx> wrote:Here is a framework for BrailleBlaster that satisfies the needs of the three major stakeholders, ViewPlus, APH and the general user community. When an xml file is opened it will also be translated, That is, rendered, by liblouisutdml according to configuration and semantic-action files. The rendering will be in a thread, since it may take a few seconds for a large document. The translation will then be displayed in the Braille window. BrailleBlaster will use Java properties files which are analogous to the liblouisutdml configuration and semantic-action files to create a DOM of the print document. This will in turn be used to display and edit the document. When the print document is edited, the block of text (paragraph, heading, etc.) being edited will be dynamically translated and displayed in the Braille window using the translateString method. If focus is shifted to the Braille window the Braille becomes editable. The Daisy window will show the part of the print document corresponding to each line in the Braille document and will not be editable. When the file is saved, edited Braille will be copied into the print document with appropriate markup and the part of the document corresponding to the edited Braille will be marked to be skipped. Users can chose to emboss the Braille or send it to a file with Save As. If either the print or the Braille has been edited the document will automatically be retranslated (rendered.) Later, liblouisutdml can be used to render the enhanced print document according to whatever configuration settings the user wishes. This may be done with BrailleBlaster or with another application that uses the liblouis-liblouisutdml transcription engine. UTDML will be used in displaying the print equivalents of braille lines and in editing Braille. Files with UTDML will be working files, not the basic format of BrailleBlaster. However, they can be saved and reopened to continue work on a particular document. They will have the extension utd We will have to think further about how tactile graphics will be handled, but UTDML will be used for this purpose also. Additional dialogues will be provided for handling liblouisutdml configuration and semantic files. Some of the features of these dialogues will be available only to advanced users. Braille editing will also be available only to advanced users. The same will be the case for creating and editing BrailleBlaster styles. (liblouisutdml styles will be handled in the configuration dialogues.) When a brf file is opened it will automatically be back-translated and the translated text will appear in the Daisy window. All blocks of characters will have the paragraph style. This can be changed by applying other styles, such as various headings. If focus is switched to the Braille window the Braille can be edited as above. Since translation and back-translation are automatic, the translate menu will be changed for retranslate and reback-trranslate. This will enable the user to see the format of Braille before embossing or saving the file. -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities
