[brailleblaster] Re: Revised frramework for BrailleBlaster
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 3 Oct 2012 11:03:14 -0400
XML can indeed be on the heavy side for verbosity. However this is not
something users have to deal with.
There is indeed support for JSON in Java but I never used it:
http://www.json.org/java
XML being a de-facto industry standard it seems to me like a better
choice. Also we would have to add yet another piece of open-source
library to an already crowded space in BB!
F.
On Wed, Oct 3, 2012 at 9:43 AM, Michael Whapples <mwhapples@xxxxxxx> wrote:
> 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
>>>
>>>
>
>
Other related posts: