[brailleblaster] Re: Editor
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Mon, 30 Jul 2012 12:35:52 -0400
Keith: translating only new or changed segments of the text will still
require formatting of the paragraphs, lines and pages in the whole
braille version, unless the user only wants an unformatted embossed
output. In both cases it's easier to translate and format everything,
except the words ane snippets that have been locked.
François.
On Mon, Jul 30, 2012 at 11:27 AM, Keith Creasy <kcreasy@xxxxxxx> wrote:
> Wouldn't you only need to translate the segment of text involved in the
> change, not the whole document? It's basically the same thing we do as we
> translate text in the Android word processor. The native edit control always
> contains plain text but the braille editor contains braille. That's on a
> phone too, not on a PC. The cursor in both controls stays synchronised though
> we did have to work around a few issues in the way LibLouis does it's offsets.
>
> Keith
>
>
>
>
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Monday, July 30, 2012 11:21 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Editor
>
> Your vision is mostly the same as mine. We are all learning what the best
> approaches are.
>
> Having a document translated when it is opened is another thing that could be
> set in the settings dialog. Many users wil not want this, and many will.
>
> A translate menu is necessary so the user can see the effects of incremental
> changes. Translating as each change is made would be a great burden on the
> processor. It would also require a lot of programming, which could be better
> spent on other things. If it is done at all,it should be after BrailleBlaster
> is substantially complete.
>
> John
>
> On Mon, Jul 30, 2012 at 03:07:58PM +0000, Keith Creasy wrote:
>> We do have somewhat different views on this. My hope was that BB would be
>> more fluid and dynamic and use the DAISY or NIMAS XML document as it's
>> native format. When the file is opened BB does it's best to render the
>> content in braille. A transcriber would then do things to fix what couldn't
>> be done well based on the XML content. Changes would be saved in the
>> original document but tagged to be shown in braille as opposed to screen or
>> print. Eventually one would end up with a DAISY or NIMAS file that contained
>> all the needed markup to produce perfect-or nearly perfect-braille. Maybe
>> that vision is too ambitious but I don't think so.
>>
>> What transcribers do now is interesting and important to know but it doesn't
>> necessarily follow that there isn't a better way. I believe there is.
>>
>>
>> Keith
>>
>> -----Original Message-----
>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of François
>> Ouellette
>> Sent: Monday, July 30, 2012 10:41 AM
>> To: brailleblaster@xxxxxxxxxxxxx
>> Subject: [brailleblaster] Re: Editor
>>
>> Keith: I agree with some of the points you make. Some of that stuff is
>> already happening when opening a UTD file, the text and included braille are
>> displayed on opening. However, if the UTD does not contain braille
>> translation only the text is displayed. You ask why would anyone save a UTD
>> file without translation? Perhaps they are working on inputting a lenghty
>> document and they are not ready to work on the braille part yet. I know some
>> experienced DBT users who do that every day, they prepare newsletters or
>> other things for which an instant translation is not desired or required.
>> When they are finish inputting and formatting the text they proceed to
>> translate and tweak the braille, then save the whole thing and emboss.
>>
>> Also the difference between UTD translation and non-UTD is related to the
>> liblouisutdml translate command, in the first case it creates text and
>> braille in elements of a UTD file, with formatting information, in the other
>> a simple text file is created for the translated braille.
>> For the GUI this option may be superfluous, if a user just wants to emboss
>> something and not save anything, we do not really care what happens in the
>> backscenes of the program, the output can be sent as is to the
>> character-mode embosser.
>>
>> I guess John will need to clarify.
>>
>> François.
>>
>> On Mon, Jul 30, 2012 at 8:20 AM, Keith Creasy <kcreasy@xxxxxxx> wrote:
>> > Guys, here are some of my thoughts about how this should work.
>> >
>> > I don't understand at all why there are two methods of translation or why
>> > one would ever want the braille view to be read-only unless it is only
>> > being used to preview which is usually not the case I think. It isn't even
>> > clear when using the program that it is different depending on whether you
>> > "Open" or "Import" the document. In fact, I don't understand why there
>> > needs to be a "Translate" menu. Why would one ever open a document using
>> > BB if they didn't intend to have it in braille?
>> >
>> > Here is how I think it should work. When I open a DAISY or NIMAS XML file
>> > I want it to open with the two views, DAISY and braille already filled
>> > with the content of the file. I then want to be able to edit in either
>> > view while the other stays synchronised. I can add braille-specific
>> > elements in the braille view that are added to the XML and have a "showin"
>> > attribute that says it is for braille. I can add a "prodNote" for image
>> > descriptions in either the braille or DAISY view.
>> >
>> > I do understand having an "Ink View" available but do not think it should
>> > be a default view. Printing braille and text in parallel is probably going
>> > to be the exception rather than the rule. I can see it being useful for
>> > teachers who do not read braille.
>> >
>> > What exactly is the difference between UTD translation and translation
>> > without it and why are there two different methods?
>> >
>> >
>> > Thanks.
>> >
>> > Keith
>> >
>> > Keith
>> >
>> >
>> > On 29/07/2012 22:20, John J. Boyer wrote:
>> >> The way BrailleBlaster works jnow, when an xml file is opened the
>> >> text is displayed in the Daisy view. This is also the case with
>> >> imported files, which are converted to xml. There are two modes of
>> >> translation, with and without UTD. In both cases the translation is
>> >> displayed in the Braille view. if the translation is done without
>> >> UTD the Braille view is read-only, since it is derived strictly
>> >> from the prinnt original. If the translation is done with UTD the
>> >> Braille view is editable, but the Daisy view is read-only, because
>> >> it is derived from the information in the UTD file and does not
>> >> correspond to the original. I feel strrongly that making it editable
>> >> would be unwise.
>> >> If the user needs to change the print original they should be able
>> >> to go back to the display shown when the file was opened.
>> >>
>> >> I want to see what the others on the team have to say. They should
>> >> be looking at the list later today or tomorrow. After all, it's Sunday.
>> >>
>> >> John B
>> >>
>> >> On Sun, Jul 29, 2012 at 08:16:50PM +0000, Keith Creasy wrote:
>> >>> 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@f
>> >>> re e lists.org> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On
>> >>> Behalf Of Keith Creasy
>> >>> Sent: Sunday, July 29, 2012 12:28 PM
>> >>> To:
>> >>> brailleblaster@xxxxxxxxxxxxx<mailto: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@f
>> >>> re e lists.org> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On
>> >>> Behalf Of John Gardner
>> >>> Sent: Sunday, July 29, 2012 3:12 PM
>> >>> To:
>> >>> brailleblaster@xxxxxxxxxxxxx<mailto: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@f
>> >>> re e lists.org> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On
>> >>> Behalf Of Keith Creasy
>> >>> Sent: Sunday, July 29, 2012 12:05 PM
>> >>> To:
>> >>> brailleblaster@xxxxxxxxxxxxx<mailto: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@f
>> >>> re e lists.org> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On
>> >>> Behalf Of John Gardner
>> >>> Sent: Sunday, July 29, 2012 3:02 PM
>> >>> To:
>> >>> brailleblaster@xxxxxxxxxxxxx<mailto: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@f
>> >>> re e lists.org> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On
>> >>> Behalf Of Keith Creasy
>> >>> Sent: Sunday, July 29, 2012 10:28 AM
>> >>> To:
>> >>> brailleblaster@xxxxxxxxxxxxx<mailto:brailleblaster@xxxxxxxxxxxxx>
>> >>> Cc: nimas@xxxxxxxxxxxx<mailto: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
>> >>>
>> >
>> >
>> >
>> >
>>
>
> --
> 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:
