[brailleblaster] Re: FW: Partial rendering
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 4 Jan 2013 17:43:16 +0000
I don't even think that is necessary. The event queue in the document takes
care of all of it including triggering a view update when a specified timer
expires. Keystrokes reset the timer so it never expires as long as the user
keeps typing fast enough. As I said, this is a proven concept and should work
quite well here. We use it under Android and use LibLouis as the translator.
The user will see the changes as the views are updated.
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John Gardner
Sent: Friday, January 04, 2013 11:16 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: FW: Partial rendering
Oh, so did I. So I'll repeat my answer. I think that users should know when
things are re-translated. So if a user types some characters into the middle
of a word, she should press something other than a "printable 95 character" key
- such as home, end, CTRL-arrow. Any of these should trigger the r-upddate
function.
I am presuming that the update will be fast enough that one can keep typing and
that the keyboard buffer will not overflow before the screen is updated.
John G
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith Creasy
Sent: Friday, January 04, 2013 7:55 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] FW: Partial rendering
John, I thought this was something for the list. I only realized afterwards
that I had replied only to you...
-----Original Message-----
From: Keith Creasy
Sent: Friday, January 04, 2013 10:51 AM
To: 'John Gardner'
Subject: RE: Partial rendering
So, what if the user just inserts chars into an existing word? No whitespace
char has been inserted but the translation still needs to be updated. I still
think an event queue based on a timer works better. Sure, you might temporarily
get something nonsensical in the braille view but within about half a second of
stopping it should correct. I use this method to allow direct editing in
contracted braille and it actually works great.
-----Original Message-----
From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx]
Sent: Friday, January 04, 2013 10:46 AM
To: 'Michael Whapples'; 'John J. Boyer'
Cc: Keith Creasy
Subject: RE: Partial rendering
Michael is absolutely right. It is not really sensible to translate until the
user inserts a white space. Even then there will be some things that change,
but translating at space, CR, TAB, etc is something that any user can
understand. I think this should be part of the spec!
John G
-----Original Message-----
From: Michael Whapples [mailto:michael.whapples@xxxxxxxxxxxx]
Sent: Friday, January 04, 2013 2:10 AM
To: John J. Boyer
Cc: Keith Creasy; John Gardner
Subject: Re: Partial rendering
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.
Other related posts:
