[brailleblaster] Re: Partial rendering
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: Michael Whapples <michael.whapples@xxxxxxxxxxxx>
- Date: Fri, 4 Jan 2013 08:39:38 -0600
Hi Michael,
You have a good point. Retranslation could be done when the spacebar is
pressed or after the user has not typed for a second or so. However, for
text nodes of reasonable length retranslating only from the point of the
change is probably not justified by the extra complication.
I am copying this message to the list, since I think that is where it
should be.
John
On Fri, Jan 04, 2013 at 10:09:53AM +0000, Michael Whapples wrote:
> I don't know what my initial view was, but certainly looking at it now,
> does this seem sensible?
>
> What I mean by this, is it wise to retranslate on every character key
> press? There will be points where it does not logically make sense to
> translate it as it will not stay that way. An example is if I were
> typing a word, until the word is complete I am not really bothered about
> how it has translated it as I will be adding more characters and the
> translation probably will change very soon.
>
> Going with the average word length being approximately 5 characters (I
> know the precise figure may differ but this is close enough and makes
> the maths easy), and assuming someone is only typing complete words (not
> correcting spelling errors), then approximately 80 percent of
> translations will be rubbish and quickly replaced.
>
> Also in most cases the translation before the insertion point will not
> change, this seems like a huge amount of retranslation which is just
> unnecessary.
>
> So I will ask the question, when is it the user wants a translation
> done? Once we know that then we can try and find the event which relates
> to that want.
>
> While being a bit more complicated to implement, I would have thought a
> more efficient thing would to wait for the user to stop typing before
> retranslating (eg. if they stop typing for a second or more). This still
> may not quite be when they want the translation done (it is my guess of
> when I would want it), so back to the question of when do they want it.
>
> Michael Whapples
> On 03/01/2013 20:03, John J. Boyer wrote:
> >We've gone through this before. I thought we had agreed that each text
> >node in an xml file would be dynamically retranslated whenever a
> >character key was pressed. This might throw page breaks, etc. off, but
> >the document could be re-rendered as a whole when it is saved. I've
> >worked out a new function for liblouisutdml to do translate single text
> >nodes, but not
> >implemennted it yet. This would be fast and shouldn't cause a noticeable
> >perfourmance hit.
> >
> >There is no need for radical changes. Just the new function.
> >
> >John V
> >
> >On Thu, Jan 03, 2013 at 06:41:04PM +0000, Keith Creasy wrote:
> >>Someone explain to me why we have to pump the entire xml document through
> >>LibLouisUTDML other than for pagenation and volume breaks? I'm thinking
> >>that we don't but maybe I'm wrong.
> >>
> >>I have some ideas but they aren't fleshed out yet.
> >>
> >>Keith
> >>
> >>
> >>
> >>Keith Creasy
> >>Software Developer
> >>American Printing House for the Blind
> >>KCreasy@xxxxxxx
> >>Phone: 502.895.2405
> >>Skype: keith537
> >>
> >>
> >>-----Original Message-----
> >>From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx]
> >>Sent: Thursday, January 03, 2013 1:17 PM
> >>To: 'Michael Whapples'
> >>Cc: Keith Creasy; 'John J. Boyer'
> >>Subject: RE: Steering committee
> >>
> >>Michael, yes there are lots of good reasons that you don't want to send
> >>page-by-page info to any printer. As for device-independence, yes it is
> >>true that the utdml Braille formatting is done for a particular page
> >>size, line length, etc. But if one wants to send it to another device,
> >>you just send the file back to liblouistdml with different parameters.
> >>At least liblouistdml is fast.
> >>
> >>I really don't see any advantage to doing anything else if the goal is
> >>getting embossed Braille. I just don't know whether it is practical to
> >>use liblouistdml for on-the-fly Braille translation/formatting. Probably
> >>not because it will spend too much time re-processing previous pages. So
> >>what one would need is some kind of differential liblouistdml that would
> >>accept everything up to page x and then translate/format everything
> >>beyond that point. Maybe not elegant, but it might be better in some
> >>ways than using style sheets. Thoughts from JJB and Keith?
> >>
> >>
> >>
> >>John
> >>
> >>
> >>-----Original Message-----
> >>From: Michael Whapples [mailto:michael.whapples@xxxxxxxxxxxx]
> >>Sent: Thursday, January 03, 2013 10:06 AM
> >>To: John Gardner
> >>Cc: 'Keith Creasy'; 'John J. Boyer'
> >>Subject: Re: Steering committee
> >>
> >>I guess with on the fly formatting, the speed would depend on how much
> >>one had to get done.
> >>
> >>An example would be if the on screen display only showed one Braille page
> >>then it only need format one page before it can show it, the rest could
> >>be done in the background or if it were fast enough done as those pages
> >>come into view.
> >>
> >>Whether for embossing one could actually start sending the first page to
> >>the embosser while formatting the next page, and so on I don't know. I
> >>get the feeling for ViewPlus embossers, possibly not as it goes through
> >>the Windows print system and for that doesn't one need to send the whole
> >>file at once, otherwise there may be a risk that something else may send
> >>its document between your pages (IE. if you sent a page at a time by
> >>sending a file which contained each page).
> >>
> >>Although I have to say it does sound a nice idea if one could have a
> >>Braille translation of a document which was device independent and it is
> >>formatted when one decides what device they will be sending it to.
> >>
> >>Michael Whapples
> >>On 03/01/2013 17:55, John Gardner wrote:
> >>>I'm not quite following the subtle details of this discussion Keith.
> >>>What I think I hear is that you would like an architecture that would
> >>>send text to liblouis (or other) to be translated as a step in the
> >>>process. Then as a separate step, you would allow CSS or XSLT to
> >>>format that Braille on the fly. I see no role for utdml in that
> >>>process. There is nothing wrong in principle with doing it your way,
> >>>but there would need to be a big development project to get the
> >>>formatting
> >>right.
> >>>FYI there is a French-led project to translate math using CSS. I
> >>>understand that it does a good job on French math and maybe others,
> >>>but it is apparently very very slow. And it is not intended to be 'on
> >>>the fly'. Is speed gonna be an issue for on-the-fly formatting?
> >>>
> >>>John
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Keith Creasy [mailto:kcreasy@xxxxxxx]
> >>>Sent: Thursday, January 03, 2013 7:46 AM
> >>>To: John Gardner; 'Michael Whapples'; 'John J. Boyer'
> >>>Subject: RE: Steering committee
> >>>
> >>>Hi John.
> >>>
> >>>The disagreement is more about how and where UTDML gets applied I
> >>>think. I assume we'll be using LibLouis UTDML perhaps with some
> >>modifications.
> >>>Yes, I do think translation and formatting are two separate things but
> >>>that's a different issue. My intent is to make them separate at some
> >>>point even if it means extending BrailleBlaster.
> >>>
> >>>As far as mainstream applications formatting braille correctly I'm not
> >>>sure what you are asking. No application that doesn't have rules for
> >>>braille are going to do it right. In that sense I do agree. I would
> >>>submit however that CSS and XSLT as well as other technologies are
> >>>pretty powerful and could go a long way toward rendering braille
> >>>correctly from any XML document type. I even had a discussion with
> >>>Brandon this morning about the possibility of using a web-based UI
> >>connected to a service.
> >>>In any case I think we've decided, once again, that we'll let
> >>>BrailleBlaster go where you, Michael, and John B. want it to go and
> >>>we'll contribute as we can. If we deccide it doesn't really work well
> >>>enough in a production environment then we'll extend it or simply
> >>>create another UI for LibLouis and LibLouis UTDML.
> >>>
> >>>
> >>>
> >>>Keith Creasy
> >>>Software Developer
> >>>American Printing House for the Blind
> >>>KCreasy@xxxxxxx
> >>>Phone: 502.895.2405
> >>>Skype: keith537
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx]
> >>>Sent: Thursday, January 03, 2013 10:28 AM
> >>>To: Keith Creasy; 'Michael Whapples'; 'John J. Boyer'
> >>>Subject: Steering committee
> >>>
> >>>Hi, I took this discussion off the list for a short steering committee
> >>>discussion. I fully approve of BB as an XML editor - it has been from
> >>>the beginning, but also from the beginning we wanted it to look and
> >>>feel like a simple WYSIWYG to novices. I think we are all on the same
> >>page here.
> >>>Where we are not on the same page is about the utdmo format, and I am
> >>>not enough of a software person to know how to bridge this gap. Utdml
> >>>was devised to be a format for embossed Braille, having all the
> >>>Braille formatting embedded. Admittedly it is a strange beast, but
> >>>the formatting is 90% of the problem in Braille "translation"
> >>>according to my friend Susan Jollly. I agree with Susan in this respect.
> >>>
> >>>My understanding is that Keith would like to have Braille formatted
> >>>separately from translation and to have it done in BrailleBlaster, not
> >>>in liblouistdml. As long as we get properly-formatted embossed
> >>>Braille out, I guess it wouldn't really matter. But in fact the
> >>>liblouistdml routine that does both is working pretty well now, and
> >>>ViewPlus is using it in virtually all new developments. It would be a
> >>>big problem for us to reverse course unless we had a really big reason
> >>>to
> >>do it.
> >>>So Keith, I guess I put this into your court. I do not believe that
> >>>any standard mainstream application can format Braille and get it
> >>>right. Am I wrong?
> >>>
> >>>John G
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: brailleblaster-bounce@xxxxxxxxxxxxx
> >>>[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
> >>>Sent: Thursday, January 03, 2013 6:50 AM
> >>>To: brailleblaster@xxxxxxxxxxxxx
> >>>Subject: [brailleblaster] Re: Different Approaches to document
> >>>processing.
> >>>
> >>>Michael.
> >>>
> >>>What other design patterns/practices do you think we should consider?
> >>>
> >>>Yes, I agree 100% that whenever possible we should use established
> >>>mainstream design practices and standards, like MVC CSS, and XSLT,
> >>>because a lot of developers already know and understand them.
> >>>
> >>>About XML editing, don't confuse the term XML Editor" with something
> >>>that has to be complicated and technical. It can still be fairly
> >>>simple. Also, I've always felt that it should be something that
> >>>doesn't have to be used by people who just want to write and print
> >>>braille. Since we are editing XML
> >>>(UTDML) then one could posit that BrailleBlaster is an XML editor
> >>>whether it appears that way or not to users.
> >>>
> >>>
> >>>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 Michael
> >>>Whapples
> >>>Sent: Thursday, January 03, 2013 9:36 AM
> >>>To: brailleblaster@xxxxxxxxxxxxx
> >>>Subject: [brailleblaster] Re: Different Approaches to document
> >>>processing.
> >>>
> >>>Hello,
> >>>I have had some concerns over the design of BrailleBlaster for a
> >>>little bit, that is partly why I decided to keep away from dealing in
> >>>the code too much and restrict myself to managing the project site and
> >>repositories.
> >>>Keith I know you mentioned about MVC, yes that probably would be a
> >>>good idea, but may be BrailleBlaster needs to make use of other design
> >>>patterns and other good practice as well. By neglecting these things
> >>>its probably made the code and design much harder to follow and means
> >>>that where one might use standard terms these might not apply or may
> >>>even have a different meaning and so leading to miscommunications.
> >>>
> >>>Regarding the use of semantic actions, I would dispute the arguement
> >>>that they are easier to use than XSL. My reasoning here again goes
> >>>along the line of using something familiar to people, XSLT is widely
> >>>used and so potential developers may already be familiar with it,
> >>>should one have a difficulty in making it do what they need then it is
> >>>much more likely they will find an answer (even if the answer is "not
> >>>possible") by searching the internet as there is much more information
> >>>out
> >>there on XSLT.
> >>>Keith you mention about defining a document interface, yes this is
> >>>something I have felt for some time, the view should have no need to
> >>>understand the underlying document format, it should deal with a
> >>>single document interface which through various adaptors/providers
> >>>will modify the document in the appropriate way. As an example, the
> >>>view should only deal with headings, it should not be concerned with
> >>>how
> >>HTML or DocX store a heading.
> >>>My understanding at present is that the semantic actions miss out the
> >>>document interface stage, mapping straight from a file format to how
> >>>they should be presented. This step really should be split, actions
> >>>for adapting the format into the document interface and actions for
> >>>how the view will render the document structure element. The former of
> >>>these would not need to be customisable by users (only developers who
> >>>want to add support for additional formats need work with it), whereas
> >>>the latter would be desirable to be customised by users (eg. sighted
> >>>users may want headings shown in a different colour, but those who are
> >>>colour blind may wish to configure it so that headings can be
> >>>distinguished without the use of colour). If one does not separate
> >>>these concerns then users may need to deal with every file format they
> >>>wish to use, meaning additional work for the user and potentially
> >>>requiring them to have fairly advanced knowledge we really should not
> >>expect of users.
> >>>As for whether BrailleBlaster should have a XML editor, my view would
> >>>be not. Such an editor would be contrary to the initial aims of
> >>>BrailleBlaster being easy to use by those with little computer
> >>>knowledge (IE. not expect more knowledge than knowing how to use a
> >>>word processor like Word), as an XML editor would require
> >>>understanding of the underlying XML format. As mentioned, if someone
> >>>wishes to have such an editor then there are probably other tools more
> >>suited for doing that XML editing.
> >>>Also I feel by spending time on features not really adding to what
> >>>BrailleBlaster is aimed to achieve will just delay BrailleBlaster ever
> >>>reaching the goal of what we want it to be.
> >>>
> >>>I know some may feel I possibly have a restricted view of what
> >>>BrailleBlaster should be, my response is that I feel keep it focused
> >>>to do a particular task for a particular type of user and do that very
> >>>well. If one tries to make something which is everything for everyone,
> >>>then it runs the risk of actually not working well for anyone (IE. its
> >>>too complicated for beginners and have annoying features for experts).
> >>>There is certainly some software I can think of which falls in the
> >>>category of trying to be everything to everyone but not working well
> >>>for anyone, where competing products while more restricted work far
> >>better.
> >>>There possibly is more, but I possibly have raised it in the past with
> >>>little affect. So in that spirit, I have pretty well said what I feel,
> >>>unless further discussion would go anywhere I don't really have much
> >>>apitite to get into big discussions now. In general I think Keith is
> >>>making some reasonable points.
> >>>
> >>>Michael Whapples
> >>>On 03/01/2013 12:45, Keith Creasy wrote:
> >>>>Yes, I've read the comments in the code and your architecture file.
> >>>>Very
> >>>helpful.
> >>>>We need to work on the interface between the views and the document.
> >>>>That
> >>>probably means defining a document interface and a view interface that
> >>>is XML centric.
> >>>>John, I'm not sure what anyone else can contribute since you want
> >>>>control
> >>>of the word processor and the document model. Until those are fleshed
> >>>out there's not really much anyone else can do. At least, speaking for
> >>>myself, I can't think of anything substantive I can contribute.
> >>>>I'm beginning to think that an XML editor really has no place here.
> >>>>Anyone
> >>>can just use an external XML editor if they need to do that.
> >>>>
> >>>>
> >>>>
> >>>>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: Thursday, January 03, 2013 1:50 AM
> >>>>To: brailleblaster@xxxxxxxxxxxxx
> >>>>Subject: [brailleblaster] Different Approaches to document processing.
> >>>>
> >>>>Hi Keith,
> >>>>
> >>>>Yes. Please do outoline your approach. There may be some here who are
> >>>>not
> >>>acvaquaintged with it. My approach is described in detail in the files
> >>>in the documentation directory of the brailleblaster.newdesign
> >>>repository. In addition, Semantics.java contains considerable
> >>>documentation in the form of javadoc comments.
> >>>>Thanks,
> >>>>John
> >>>>
> >>>>--
> >>>>John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
> >>>>http://www.abilitiessoft.com
> >>>>Madison, Wisconsin USA
> >>>>Developing software for people with disabilities
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>--
> >>________________________________
> >>
> >>Michael Whapples | Software engineer | ViewPlus
> >>541.754.4002 x 282 | www.viewplus.com
> >>________________________________
> >>PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with
> >>it may be proprietary and are intended solely for the use of the
> >>individual to whom they are addressed. If you are not the intended
> >>recipient, any use, copying, disclosure, dissemination or distribution is
> >>strictly prohibited; please notify the sender and delete the message.
> >>ViewPlus Technologies, Inc.
> >>accepts no liability for damage of any kind resulting from this email.
> >>
>
> --
> ________________________________
>
> Michael Whapples | Software engineer | ViewPlus
> 541.754.4002 x 282 | www.viewplus.com
> ________________________________
> PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with it
> may be proprietary and are intended solely for the use of the individual to
> whom they are addressed. If you are not the intended recipient, any use,
> copying, disclosure, dissemination or distribution is strictly prohibited;
> please notify the sender and delete the message. ViewPlus Technologies,
> Inc. accepts no liability for damage of any kind resulting from this email.
--
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:
