[brailleblaster] Re: Revised frramework for BrailleBlaster
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 3 Oct 2012 13:55:23 -0400
I think the main point here is that we should not pick one over the
other for "ease of use by the user", since users should not be
involved with the internals of an application program.
If they want to edit a style and set a number of empty lines before a
paragraph, the GUI shows them something that allows them to set the
value, not the actual content of the properties file to edit!
The same as if you to create or change a style in Microsoft Word, you
deal with user-oriented popups with drop-down lists and checkboxes,
not creating the underlying parameter values used by the software.
JSON stands in between properties files and XML and may be good enough
for most needs, XML is more robust and follows a strict standard. JSON
is most useful with HTML.
But it's probably just me, based on 40 years of software development
experience...
F.
On Wed, Oct 3, 2012 at 12:18 PM, Keith Creasy <kcreasy@xxxxxxx> wrote:
> XML is a little more complicated. No strong feelings either way on my part.
>
>
> 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 John J. Boyer
> Sent: Wednesday, October 03, 2012 10:34 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Revised frramework for BrailleBlaster
>
> The configuration and semantic-action files are basically key-value pairs,
> though the value may be a bit complicated. It seems to me that using xml for
> them is more complex than needed.
>
> John
>
> On Wed, Oct 03, 2012 at 08:07:13AM -0400, 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
>> >
>> >
>
> --
> 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:
