[brailleblaster] Re: Revised frramework for BrailleBlaster
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 3 Oct 2012 11:09:14 -0400
Yes but users should normally NOT be involved in the internals of a
configuration file or any programming component!
A good GUI deals with user commands, not how the stuff is internally stored.
Old editors from the 1980's like WordPerfect needed the user to enter
cryptic commands to format the text.
If there is a function to maintain styles it should not require the
user to know what the properties look like at the programming level.
There only should be buttons and fields to record and edit the values,
not to be involved with internal keynames and codes.
F.
On Wed, Oct 3, 2012 at 9:56 AM, Keith Creasy <kcreasy@xxxxxxx> wrote:
> I agree.
>
> The only reason I can think of for using "properties" files is that they are
> easier to read in a text editor.
>
> Keith Creasy
> Software Developer
> American Printing House for the Blind
> KCreasy@xxxxxxx
> Phone: 502.895.2405
> Skype: keith537
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of François Ouellette
> Sent: Wednesday, October 03, 2012 8:07 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Revised frramework for BrailleBlaster
>
> 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:
