[brailleblaster] Re: Steering: Design outline
- From: Brandon Roller <brandon.r.roller@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Thu, 10 Jan 2013 12:40:02 -0500
Hello John,
I have started some early work on a tree view and I think that to begin
implementing it, the views need a way to access the XML Dom created by the
semantics class. Essentially two methods are needed, a getNodes class and
a getContextNode. The getNodes class would be used to obtain a reference
to all or a portion of the DOM. It can take two expressions a Node and an
Xpath expression. If the null is passed as the node, then the root is
returned by default.
The getContextNode method would return the current node, the getContextNode
method would be used when update evetns occur so that the tree or other
view can be changed. I think a getter method for a single or multiple
nodes from the document class is a good start since the tree view is read
only.
-Brandon
On Thu, Jan 10, 2013 at 12:08 PM, John J. Boyer <john@xxxxxxxxxxxxxx> wrote:
> Hi Keith,
>
> I thougt you and the other APH developers would concentrate on the
> views. I want to concentrate on the document package. I would rather not
> have to work on anything else except BBIni and maybe some utilities.
> There are also the importers and exporters packages and the embossers
> and printers packages. Someone could also take over the settings package
> and expand the userSettings.properties file to record such things as
> which view the user prefers. In the wordprocessor, the Document Manager
> class needs an overhaul. It now contains a lot of stuff which should be
> in other classes, such as importers. RecentDocuments also needs some
> work. What should it contain for files from a zip archive or from the
> Internet?
>
> John B
>
>
> On Thu, Jan 10,
> 2013 at 04:54:44PM +0000, Keith Creasy wrote:
> > I guess what I'm asking is, since you have the master strategy and seem
> pretty firm on it, what if any of this should Chuck, Brandon, and I take
> responsibility for? At this point I am unsure how to proceed, or should we
> just wait?
> >
> >
> >
> > -----Original Message-----
> > From: John J. Boyer [mailto:john.boyer@xxxxxxxxxxxxxxxxx]
> > Sent: Thursday, January 10, 2013 11:21 AM
> > To: Keith Creasy
> > Cc: Michael Whapples; John Gardner
> > Subject: Re: Steering: Design outline
> >
> > Hi Keith,
> >
> > I really can't come up with specific suggestions for Chuck and Brandon.
> > You know them better than I do. However, I would like to know what
> information the developers want to pass in and out of the document package,
> so I can set up methods in the Document class. These are technical matters
> and should be on the list.
> >
> > John B
> >
> > On Thu, Jan 10, 2013 at 02:00:14PM +0000, Keith Creasy wrote:
> > > Yes, well I think we already agree on those two points. I also think
> your strategy for using semantic actions is fine too. I probably would not
> have done it that way but it most likely doesn't matter much. It boils down
> to the fact that I'd have used conventional XML features more; things like
> schemas, XSLT, and XPath.
> > >
> > > I am trying to get my head around your strategy and I think I'm
> getting there. Your recent changes actually helped.
> > >
> > > I am anxious to get things to a point that we can assign different
> components to our developers and let them get going with it. Any
> suggestions for Chuck and Brandon?
> > >
> > > Styled text works for what we want to do initially. I still haven't
> found the reference to support for images but then I haven't looked at all
> the links Michael sent. I'm excited that image support might be in there
> because it opens up all kinds of possibilities.
> > >
> > >
> > > I still think the document methods need to be event driven, threaded,
> and queued.
> > >
> > > -----Original Message-----
> > > From: John J. Boyer [mailto:john.boyer@xxxxxxxxxxxxxxxxx]
> > > Sent: Wednesday, January 09, 2013 6:18 PM
> > > To: Keith Creasy
> > > Cc: Yuemei Sun; John Gardner; Michael Whapples
> > > Subject: Re: Steering: Design outline
> > >
> > > I think we can agree on two things. It would be desirable for
> BrailleBlaster to be vocabulary-agnostic. To accomplish this it is
> necessary to have classer or a wrapper that encapsulates knowledge of the
> vocabulary of the particular document and presents the rest of the
> application with an abstraction. I am familiar with the use of
> semantic-action files and have been considering extending them from their
> use in liblouisutdml to generalized rendering and editing for quite some
> time. Other approaches to attaining the two goals listed above are
> possible, but this is one backed by years of experience and refinemment.
> > >
> > > On other matters, StyledText and StyledTextContent require
> considerable mental work. There are other classes in the SWT custom package
> which we might find helpful, including a printing class. StyledText itself
> can convert to RTF, so it may take care of one export need.
> > >
> > > If we agree on the two things stated at the beginning of this message
> I think we can proceed. I will work on the details of editing and updating
> and will also investigate the use of XPath. The Document class will consist
> of a large number of convenience methods, some with short bodies.
> > >
> > > John B
> > >
> > > On Wed, Jan 09, 2013 at 08:32:18PM +0000, Keith Creasy wrote:
> > > > Thank you. I understood all this but your explanation is appreciated.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Yuemei Sun [mailto:yuemei.sun@xxxxxxxxxxxx]
> > > > Sent: Wednesday, January 09, 2013 3:24 PM
> > > > To: John J. Boyer
> > > > Cc: Keith Creasy; John Gardner; Michael Whapples
> > > > Subject: Re: Steering: Design outline
> > > >
> > > > I will see if I can explain a little bit about the use of
> libouisutdml/semantic files.
> > > >
> > > > ViewPlus uses liblouisUTDML to translate OpenOffice.org Writer and
> Calc document into braille documents with matching ink texts interlined .
> We extract the content xml from the Zipped OOo file and send it to
> libouisutdml. In return, we get an XML with UTDML (<brl> blocks) embedded.
> The <brl> blocks has braille formatting information, such as <newline>,
> <newPage> etc, and the mapping info from braille to the original texts.
> > > >
> > > > We process the returned document in a way that the Braille will be
> formatted as specified in the <brl> block, and the texts will be extracted
> according to the mapping info. The braille will be put in one layer
> (transparent) and the ink will be in another layer (also transparent), but
> formatted in a way so that it will appear between braille lines. The UTDML
> block is then removed from the returned document, and the document is
> zipped back into an ODT or ODS document which will be opened again in
> OpenOffice.org.
> > > >
> > > > One of the most important reasons that ViewPlus uses liblouisutdml
> is the correct braille formatting included in the translated braille, for
> example, the braille page numbers included in the translated texts.
> > > > This can only be done during the translation stage. Braille
> formatting/style has their complex rules and liblouistutdml knows how to
> handle them.
> > > >
> > > > In my understanding, semantic-action files, used by liblouisutdml,
> is a way to specify how every element in the document is to be handled.
> When an OOo xml file was first sent to liblouisutdml, a .sem file
> (document-content.sem), named after the root element, was created, with all
> the element listed and set to default action "no", which means no action is
> to be performed. In order to translate, I need to edit the .sem file to
> specify which elements should be performed a translation action. Later on,
> I learned to use the .sem file to specify more customized action, such as
> applying specific translation table for elements having certain attributes.
> > > >
> > > > The semantic-action mechanism used in liblouisutdml has it
> flexibility of introducing new actions and of specifying actions on
> individual elements. Those actions do not have to be a translate action.
> I can see why John B. argues that the same mechanism can be used for
> editing XML document in general. Semantic-action machanism is independent
> from UTDML. It was first used in liblouisxml; we added UTDML spec later in
> order to have the ink-braille mapping info in the translated file.
> > > >
> > > > Yuemei
> > > >
> > > >
> > > > On 1/9/2013 6:16 AM, John J. Boyer wrote:
> > > > > Keith, you are by no means stupid, but this involves thinking
> > > > > outside the box. I think I have stated what semantic actions do
> quite clearly.
> > > > > It's true that in liblouisutdml they are used to render documents
> > > > > into Braille. In BrailleBlaster I have used what I learned in
> liblouisutdml.
> > > > > The role of semantic action files is to tell the program how to
> > > > > handle documents and how to edit them.
> > > > >
> > > > > Please remember to use reply-to-all when answering messages to the
> > > > > steering committee. There are people at ViewPlus who do understand
> > > > > semantic-action files. Perhaps they can help.
> > > > >
> > > > > John B
> > > > >
> > > > > On Wed, Jan 09, 2013 at 01:59:27PM +0000, Keith Creasy wrote:
> > > > >> John.
> > > > >>
> > > > >> I'm come to the conclusion that I am completely in the dark about
> exactly what semantics and styles do, outside a view, and it is very
> confusing that you use semantic action files in LibLouisUTDML and have
> something with the same name that does something different in the document
> class. If LibLouis UTDML does everything that is needed to style and format
> braille then what is the point?
> > > > >>
> > > > >> I do, of course, understand what "semantics" are and that they
> give some commonly understood meaning to elements. Your strategy on how
> they get used and where you chose to put it completely baffles me.
> > > > >>
> > > > >> Does anyone else but you understand this? It totally makes no
> sense to me. Maybe someone who does understand it can call and explain it
> because the comments and email just isn't doing the trick.
> > > > >>
> > > > >> Sorry. Maybe I'm just stupid but I'm here anyway and really do
> need to understand.
> > > > >>
> > > > >>
> > > > >> Keith Creasy
> > > > >> Software Developer
> > > > >> American Printing House for the Blind KCreasy@xxxxxxx
> > > > >> Phone: 502.895.2405
> > > > >> Skype: keith537
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: John J. Boyer [mailto:john.boyer@xxxxxxxxxxxxxxxxx]
> > > > >> Sent: Wednesday, January 09, 2013 8:44 AM
> > > > >> To: Keith Creasy
> > > > >> Cc: Michael Whapples; John Gardner; Yuemei Sun
> > > > >> Subject: Re: Steering: Design outline
> > > > >>
> > > > >> Hi Keith,
> > > > >>
> > > > >> We are still talking past each other. The Semantics class has
> very little to do with Braille markup. Everything pertaining to Braille and
> tactile graphics is contained in UTDML. Semantic-action files and the
> Semantics class in general attach meaning to markup in the document. It is
> analogous to how compilers attach code to tokens and constructs in a
> grammar. Semantics deals with the entire document.
> > > > >>
> > > > >> Styles are used to layout content in a wordprocessor-like view of
> the document. They have nothing to do with Braille, because Braille is
> completely described by UTDML.
> > > > >>
> > > > >> I see the Document wrapper class as making the semantics
> machinery a "black box". Other parts of BrailleBlaster would call methods
> in this class or trigger events which would be picked up by listeners.
> > > > >>
> > > > >> Taking a tree view as an example, the view would call a method
> that would provide the information for each element. This information would
> include depth.
> > > > >>
> > > > >> I think this matter is for the steering committee only and should
> not be on the public list.
> > > > >>
> > > > >> John B
> > > > >>
> > > > >> On Wed, Jan 09, 2013 at 01:07:59PM +0000, Keith Creasy wrote:
> > > > >>> OK, that's great about the styled text view. I didn't see
> anything in the docs I read about graphics or hosting controls but if it
> does that then it makes everything easier.
> > > > >>>
> > > > >>> I don't know how it effects your renaming of the document and
> the Semantics class. One thing for sure, and at the risk of beating a dead
> horse, I think the Semantics stuff belongs in a Semantics class that the
> document uses to add braille markup and not in the document class itself.
> In other words, all the semantics functionality needs to be encapsulated.
> > > > >>>
> > > > >>> How would you like to harmonize my design outline and your own
> plans for implementing semantics and styles?
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: John J. Boyer [mailto:john.boyer@xxxxxxxxxxxxxxxxx]
> > > > >>> Sent: Tuesday, January 08, 2013 6:53 PM
> > > > >>> To: Keith Creasy
> > > > >>> Cc: John Gardner; 'Yuemei Sun'; 'Michael Whapples'
> > > > >>> Subject: Re: Steering: Design outline
> > > > >>>
> > > > >>> Some comments.
> > > > >>>
> > > > >>> StyledText can handle graphics. There are methods and events
> especially for this.
> > > > >>>
> > > > >>> Will one of the views display the document content, including
> images in a format similar to a word processor, without synchronizing with
> the Braille? Styles would be appropriate here.
> > > > >>>
> > > > >>> Since the Braille and tactile graphics are completely specified
> by the UTDML styles are neither necessary or appropriate for the Braille
> view.
> > > > >>>
> > > > >>> I am implementing the suggestion for the
> org.brailleblaster.document.Document wrapper class. It should be in the
> repository soon. How will this fit in with the rest of the design?
> > > > >>>
> > > > >>> John B
> > > > >>>
> > > > >>> On Tue, Jan 08, 2013 at 08:20:27PM +0000, Keith Creasy wrote:
> > > > >>>> For sure. It is a challenge.
> > > > >>>>
> > > > >>>> I think the advantage is that the views are "pluggable". Unless
> I'm mistaken the SWT styled text view won't do it. If we do a good job of
> designing the document/view interface then when Yuemei designs her awesome
> editable HTML view and you design your awesome interleaved text/braille
> view it's just a matter of adding it to the list of views that can be
> opened and attached to the document. In the meantime our pair of styled
> text views gets us at least to the point of having a functional XML braille
> editor.
> > > > >>>>
> > > > >>>> I think it is going to be very important to define our document
> interface carefully and as completely as possible.
> > > > >>>>
> > > > >>>> From: John Gardner [mailto:john.gardner@xxxxxxxxxxxx]
> > > > >>>> Sent: Tuesday, January 08, 2013 3:04 PM
> > > > >>>> To: Keith Creasy; 'Yuemei Sun'
> > > > >>>> Cc: 'John J. Boyer'; 'Michael Whapples'
> > > > >>>> Subject: RE: Steering: Design outline
> > > > >>>>
> > > > >>>> And the plot thickens. Most math equations are actually
> in-line, so the text view would need to handle in-line graphics. The
> Braille view could get by with "stand alone" graphics, because the in-line
> equation is Braille or at least something tactile. Formatting to show math
> in the text view to correspond in position with Braille math has been a big
> challenge for Yuemei.
> > > > >>>>
> > > > >>>> John G
> > > > >>>>
> > > > >>>>
> > > > >>>> From: Keith Creasy [mailto:kcreasy@xxxxxxx]
> > > > >>>> Sent: Tuesday, January 08, 2013 11:57
> > > > >>>> To: Yuemei Sun
> > > > >>>> Cc: John Gardner; 'John J. Boyer'; 'Michael Whapples'
> > > > >>>> Subject: RE: Steering: Design outline
> > > > >>>>
> > > > >>>> Hi Yuemei.
> > > > >>>>
> > > > >>>> You are running a bit ahead of me here. I sure hope we can
> allow for graphics to be displayed in the text view but I'm not sure how we
> can do it initially. So the answer is, I hope so. . It's just a matter of
> writing and plugging in a different view of the document.
> > > > >>>>
> > > > >>>> Having the graphic available isn't a problem but implementing a
> > > > >>>> view that can handle graphics and OLE objects is not a trivial
> undertaking.
> > > > >>>> I do think that, using this design, the styled text view could
> > > > >>>> be replaced with one that can do more
> > > > >>>>
> > > > >>>>
> > > > >>>> From: Yuemei Sun [mailto:yuemei.sun@xxxxxxxxxxxx]
> > > > >>>> Sent: Tuesday, January 08, 2013 2:51 PM
> > > > >>>> To: Keith Creasy
> > > > >>>> Cc: John Gardner; 'John J. Boyer'; 'Michael Whapples'
> > > > >>>> Subject: Re: Steering: Design outline
> > > > >>>>
> > > > >>>> Would Math/Graphics be reflected in the views? The math
> braille would already be in the braille view, but the original math input
> would likely be an OLE object or a graphics image, how would it be included
> in the text view? If the XML contains graphics, will it be included in
> both views?
> > > > >>>>
> > > > >>>> Yuemei
> > > > >>>> On 1/8/2013 11:29 AM, Keith Creasy wrote:
> > > > >>>> Yes, the text and braille views should display line-by-line and
> be synchronized.
> > > > >>>>
> > > > >>>> Since the braille view actually uses the braille output of
> LibLouisUTDML then it would indeed have to be processed through it first.
> If we can just get the XML document and views to work though I think we're
> well on the way. At some point we'll need to add functionality to re-render
> just segments of an XML document through LibLouisUTDML in order to update
> the braille view but we don't have to have that to get everything else
> working. We do, however, have to design this in such a way that we can do
> that when we are ready.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Keith Creasy
> > > > >>>> Software Developer
> > > > >>>> American Printing House for the Blind
> > > > >>>> KCreasy@xxxxxxx<mailto:KCreasy@xxxxxxx>
> > > > >>>> Phone: 502.895.2405
> > > > >>>> Skype: keith537
> > > > >>>>
> > > > >>>> From: Yuemei Sun [mailto:yuemei.sun@xxxxxxxxxxxx]
> > > > >>>> Sent: Tuesday, January 08, 2013 2:23 PM
> > > > >>>> To: John Gardner
> > > > >>>> Cc: Keith Creasy; 'John J. Boyer'; 'Michael Whapples'
> > > > >>>> Subject: Re: Steering: Design outline
> > > > >>>>
> > > > >>>>
> > > > >>>> I have the same question as John G. about the "text" view. If
> the "text" view is to have the option of having it formatted to match the
> braille view line by line, the XML Dom Document will need to have UTDML
> info in it, which specifies the mapping from texts to braille. In that
> case, the semantic action would have been applied to the original XML
> document.
> > > > >>>>
> > > > >>>> Yuemei
> > > > >>>> On 1/8/2013 10:31 AM, John Gardner wrote:
> > > > >>>> Keith, what is the "text" view? Does one have the option of
> having it formatted by utdml to match the Braille view? My thought is that
> one could have a menu option to have text automatically formatted so that
> each line corresponds to the Braille, or to have it formatted
> normally/Braille-match on some toggle command. That would be elegant. I'm
> concerned about having too many views. So a non-expert would presumably be
> able to have only two views - braille and text. An expert could also look
> at the XML tree and/or a XML document formatted somehow to show structure.
> > > > >>>>
> > > > >>>> I don't understand most of the detail, so I'll ask Michael and
> Yuemei to comment. I'm copying Yuemei on this with the note that it is
> steering committee business, not for the full list.
> > > > >>>>
> > > > >>>> Thanks.
> > > > >>>> John G
> > > > >>>>
> > > > >>>>
> > > > >>>> From: Keith Creasy [mailto:kcreasy@xxxxxxx]
> > > > >>>> Sent: Tuesday, January 08, 2013 09:32
> > > > >>>> To: John J. Boyer; John Gardner; 'Michael Whapples'
> > > > >>>> Subject: Steering: Design outline
> > > > >>>>
> > > > >>>> Gentlemen.
> > > > >>>>
> > > > >>>> I'm not ready to make this public but thought I'd send it to
> you so that you are aware of where my thinking is going at this point.
> Also, you may have ideas and suggestions. It certainly isn't final or
> definite but we are at least discussing it among ourselves here at APH in
> order to get going in what hopefully is a helpful direction. See below.
> > > > >>>>
> > > > >>>>
> > > > >>>> Braille Blaster document/view Design
> > > > >>>>
> > > > >>>> One of the factors in the design of BrailleBlaster is the
> ability to edit text, update an XML DOM document, and also update all the
> views of that document dynamically. When text or braille changes, or when a
> new node in the XML is selected the braille, text, tree view, and/or HTML
> view have to likewise be updated. To deal with this I am proposing a
> solution with these key elements:
> > > > >>>>
> > > > >>>> 1. The option of attaching at least four views to a single XML
> Document; braille, text, structure tree, and HTML.
> > > > >>>> 2. A map that matches each text node in an XML document with
> the print offset where that text node starts. Synchronizing the braille
> version is also involved.
> > > > >>>> 3. A queue of events that is managed by the document so that
> when a view changes the text or selection the document can be updated in
> the order in which these updates occurred.
> > > > >>>> 4. a method in the document postEvent that is called by any
> view that needs to update the XML content.
> > > > >>>> 5. Each view implements methods onUpdateText and
> onUpdateSelection as needed so that the contents of that view can update.
> > > > >>>>
> > > > >>>> The scope in this portion of the design is to deal with the
> process of editing and updating an XML dom and dynamically updating and
> synchronizing several views of that document. We won't deal with applying
> styles to braille or print or using the "semantic action files (.sem)".
> > > > >>>>
> > > > >>>>
> > > > >>>> Document class
> > > > >>>>
> > > > >>>> The document class wraps the XOM XML document and implements,
> for the purposes of the user interface, methods that handle events fired
> from the various views. These might include:
> > > > >>>>
> > > > >>>> postEvent (We could add convenience methods like
> > > > >>>> postUpdateTextEvent) updateViews setSelection updateText
> > > > >>>> insertNode splitNode mergeNode deleteNode attachView detachView
> > > > >>>> translateNode readXML writeXML
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Also, some "getter" methods that the views can use:
> > > > >>>>
> > > > >>>> getText
> > > > >>>> getBraille
> > > > >>>> getInsertionPoint
> > > > >>>> getSelection
> > > > >>>> getNode
> > > > >>>>
> > > > >>>>
> > > > >>>> There may be others and the precise arguments required are yet
> to be defined.
> > > > >>>>
> > > > >>>> The document maintains a "cursor" that points to a specific
> > > > >>>> text node in the XML document and a corresponding offset. There
> > > > >>>> is also a map of the text nodes with a start offset so that one
> > > > >>>> and only one position in the textual content is considered the
> > > > >>>> current insertion point. The document also maintains a
> > > > >>>> "selection" that represents a range of text either before or
> > > > >>>> after the current cursor position
> > > > >>>>
> > > > >>>>
> > > > >>>> EventHandler
> > > > >>>>
> > > > >>>> The event handler queues events received through the Document's
> postEvent method. Events are queued in a FIFO order and are tied to a timer
> that controls the rate at which events are processed. The handler calls the
> methods in the document that actually make changes to the XMLDOM. The event
> handler runs in its own thread and only it has access to change the
> document.
> > > > >>>>
> > > > >>>> The postEvent method does two things. It adds the event to the
> end of the queue and resets a timer that controls when the event queue gets
> processed. When the timer expires then a "processEvents method is called
> and all pending events are processed and applied.
> > > > >>>>
> > > > >>>> Processing events
> > > > >>>>
> > > > >>>> Events are processed in FIFO order. If a sequence of events can
> be merged; i.e. several individual character insertion events are
> consecutive, they are merged before being processed. In this way the number
> of actual changes to the XML DOM is reduced as well as the number of
> updates to the views.
> > > > >>>>
> > > > >>>> Events, after processing, include an identifier to indicate
> which view requested the change. The updateViews method in the document is
> called that notifies the views of a change and each view updates it's
> content accordingly.
> > > > >>>>
> > > > >>>>
> > > > >>>> Proposal summary
> > > > >>>>
> > > > >>>> I propose that APH developers begin work on this architecture
> to dynamically edit XML documents including text, braille, and changes to
> the XML document structure. This is independent of Abilitiessoft' (John
> Boyer's) work on Semantic Action And styles. We plan to focus only on
> editing text and managing an XML DOM in a dynamic way using all four views.
> Our intention is to incorporate John's work at some future point when both
> efforts are developed further.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>>
> > > > >>>> ________________________________________
> > > > >>>>
> > > > >>>> Yuemei Sun | Software Engineer |
> > > > >>>>
> > > > >>>> 541.754.4002 ext. 229 | www.viewplus.com<
> http://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.
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>>
> > > > >>>> ________________________________________
> > > > >>>>
> > > > >>>> Yuemei Sun | Software Engineer |
> > > > >>>>
> > > > >>>> 541.754.4002 ext. 229 | www.viewplus.com<
> http://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
> > > > >> --
> > > > >> John J. Boyer; President, Chief Software Developer Abilitiessoft,
> Inc.
> > > > >> http://www.abilitiessoft.com
> > > > >> Madison, Wisconsin USA
> > > > >> Developing software for people with disabilities
> > > >
> > > > --
> > > > ________________________________________
> > > > Yuemei Sun | Software Engineer |
> > > > 541.754.4002 ext. 229 | 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
> >
> > --
> > 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, Executive Director
> GodTouches Digital Ministry, Inc.
> http://www.godtouches.org
> Madison, Wisconsin, USA
> Peace, Love, Service
>
>
>
Other related posts:
