[brailleblaster] Re: Revised frramework for BrailleBlaster
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 3 Oct 2012 12:15:20 -0500
We are miscommunicating. I am not saying that users will be handling
configuration files or semantic-action files. I'm just saying that Java
properties files are the simplest way to represent that information. The
/gUI will have dialogues to deal with it.
John
On Wed, Oct 03, 2012 at 11:09:14AM -0400, Franïois Ouellette wrote:
> 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
> >>
> >>
> >
> >
--
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:
