[brailleblaster] Re: Editor
- From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Sun, 29 Jul 2012 14:44:32 -0700
Keith, I'm not being very clear I guess. There are only two views. The ink
view is a reformatting of the text so that it matches up with the braille.
So the transcriber sees text and braille together. Ideally we will have an
interlined view but two views seemed easier to create at the beginning. It
is important to me as well, because ViewPlus has a number of
printer/embossers that will print that ink view on the braille with the text
is interlined.
I am presuming that the ink view will simply replace the standard-formatted
text in its window after the translation.
Are we communicating better?
John G
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
Sent: Sunday, July 29, 2012 1:17 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editor
I'm not sure. I invision only two views. One for braille and one for
XML/HTML rendering of the text from the XML file. They should both
dynamically update as changes are made. Why would we need a third view for
the text from the braille view?
Keith
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John Gardner
Sent: Sunday, July 29, 2012 4:09 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editor
Keith, okay I'm confused again. What is your second view? Seems to me you
need a regular text view when viewing the original XML file, and then you
need a dual view of the translated document - one showing the braille and
one showing the accompanying ink - basically a reformatted version of the
regular view. This is what I called the "ink view". I hope that we are not
working from different models of what BB is supposed to do.
My original vision was that users would create or import a document, and
when it is more or less finished, translate it. From that point on, one is
no longer working with the original XML document - one is working with the
UTD document. The text on screen is the same but formatted to match the
braille, so all lines are very short. A smart user would do little or no
editing of text in such a document but can edit the braille as she chooses.
Since almost any braille editing is gonna cause line/page wrap problems, one
should re-translate before embossing the final copy. To keep true
synchronization between the braille and ink copy, BB would need to
re-translate continually, and that seems pretty heavy overhead to me.
Keeping the portions scrolling together might be a much easier problem, but
it might not be trivial to take account of how line wrapping in one view is
to be handled when scrolling.
I don't know much about displaying graphics. Huge files are a big problem,
and displaying graphics just makes them lots harder. But you need to have
the graphics.
John G
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
Sent: Sunday, July 29, 2012 12:28 PM
To: brailleblaster@xxxxxxxxxxxxx
Cc: Chuck Myers; Mark Klarer
Subject: [brailleblaster] Re: Editor
That's what I thought but John B. seems to prefer directly editing XML. So,
my position is that either way we need that ability to make the DAISY
view/editor as visually functional as possible. At a minimum it needs to
format the text in a sane manner and include images. Ideally it should also
respect style attributes and CSS. This is an essential component if BB is
ever going to appeal to 99% of the braille transcribers and producers out
there.
The model I had in mind is a base XML document with two views. Both views
update the document dynamically and the parent view handles tex-change
events. There are a lot of details to work out but I think an HTML editor
view would work. As we do this we can better encapsulate the document/view
objects so that an MDI feature is more easily implemented if that is
something folks want.
Another thing to consider is that several tools, including Word, is choaking
on the larger NIMAS files so opening and rendering the entire XML document
at once may not even be practical. The XML DOM plus images can get very
large. We can probably open the entire XML document but I doubt that we can
render the entire thing with images. At least the images need to be loaded
and rendered on an as-needed basis.
Let's keep talking about this. Some of what others are doing may need to be
suspended until some decisions are made.
Keith
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John Gardner
Sent: Sunday, July 29, 2012 3:12 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editor
Hi Keith, continuous synching was not specified originally in order to keep
BB version 1 as simple as possible. However if it is really easy to do,
nobody would have any objection to it being added.
I guess I am confused about the XML display problem. To my knowledge, it
should be possible to map any of the XML formats that we plan to support
onto HTML, so I see no real problem in using a HTML visual display. What am
I missing here?
John G
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
Sent: Sunday, July 29, 2012 12:05 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editor
I disagree about the need for them to be continuously synchronised. I
believe they should be. Doing so is not a momumental task, much easier than
coming up with the kind of XML editor we need for example. :)
A sighted braille transcriber is going to want the two to match as they work
with changes in one immdiately reflected in the other.
Just my opinion.
Keith
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John Gardner
Sent: Sunday, July 29, 2012 3:02 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Editor
Hello Keith. A few comments. I don't understand why the braille view is
read-only. The braille needs to be editable according to the specs. We
have discussed several possibilities for synchronizing the braille and text
views. They don't need to be continuously synchronized, but one does need
to have some button to push to synch them. Synching means nothing more than
putting the cursor more or less in the right place. To fully update both,
one retranslates. After locking the braille changes of course! Of course
one could do some more fancy synching, but this should be pretty
straightforward to implement, and fancier things are likely to be a big can
of worms.
You brought up the subject of images and math, and I have forgotten the
specs for those. It is worth having a discussion at this point about the
minimum needed for BrailleBlaster version 1.0. I don't know how one
includes images into embosser data for conventional embossers, but I do know
how ViewPlus embossers handle them. The ViewPlus printer driver just
converts them to dots and sends the image to the embosser along with the
braille. This should be easy to include in the braille view. And the image
should also be reproduced in the "ink view".
Math should be included as MathML,and liblouis can convert it to several
possible math codes. Any math images will need to be converted by the user
to MathML to be translatable. The math braille will be automatically
included in the braille view, and the math image should be included in the
ink view. Interestingly, if one chooses to use DotsPlus for math, it can be
treated as an image in both views without any translation required.
There is still a lot to do with BB, but I agree with you that we need to
think forward about the tools we are using.
John G
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
Sent: Sunday, July 29, 2012 10:28 AM
To: brailleblaster@xxxxxxxxxxxxx
Cc: nimas@xxxxxxxxxxxx
Subject: [brailleblaster] Editor
I've spent some time this weekend looking over the current state of
BrailleBlaster. My main thoughts so far are:
The text editor/view needs to display the DAISY/NIMAS document as HTML with
mixed fonts and images. Maybe we could use something like
http://djproject.sourceforge.net/ns/ to do this? Please check it out and
share your thoughts. Showing images is important since many textbooks
contain images that need descriptions and also use images for such things as
diagrams and math equations. This is where BB can shine by providing a nice
user interface for expressing these items in text or Nemeth braille. XSL
transforms can be used to render the XML to HTML for viewing and editing.
Along with this is the need to support or allow one to use a braille display
and keyboard to directly edit in the braille view. Maybe the screen readers
can be used to make this work. Not sure. It would be great if the braille
keyboard/display could be locked onto the braille view somehow.
The braille view is read-only. We can probably use the current StyledText
view for editing braille since we won't need images or mixed fonts in
braille.
We'll need a mechanism for synchronising the two views. I'm thinking the
parent view can be notified of any edits to either view and then send a
message with the view that changed and an object containing information
about the change. Android has a nice structure for doing this and LibLouis
provides information about the current offsets for braille and text. We use
this for the Braille Plus' braille editor to synchronise the braille editor
with the edit control in the Android app.
In my opinion this is what is most needed in BB to make it the kind of
powerful tool we want and need. Let's think about this and try to identify
the best way to get this accomplished. I'm willing to put in some developer
time-my own time-to work on it but we need to agree on what
libraries/controls to use.
Also, we found a translation bug in LibLouis but our library is out of date.
Does anyone know off hand if it still reverse-translates "update" to
"upaidate"?
Thanks.
Keith
Other related posts:
