[brailleblaster] Re: What will the text view show?
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Thu, 24 Jan 2013 14:00:45 -0600
Hi Keith,
This sounds good. However, it leaves me uncertain what to develop in the
document package. I may work on liblouisutdml and liblouis until things
are more settled. Meanwhile, if BrailleBlaster can open an xml file and
call StartDocument, I can test what I have already. That is an essential
step.
On another subject, I think that the UTD class might be folded into the
Braille view. It contains a lot of stuff that needs to be stripped out,
including a reference to the <p> element, which is not part of UTDML.
John
On Thu, Jan 24, 2013 at 05:50:56PM +0000, Keith Creasy wrote:
> Hi John.
>
> These are mostly notes from this mornings meetings.
>
> Yes, for the browser view we just about have to use XSLT. I know there are
> transformations for DTBook and NIMAS. I'm not sure about others but they
> really are not that hard to create if they don't exist.
>
> The thing we talked about this morning is how to map segments of text by
> offset to the DOM text nodes. I think what we decided is that we do need a
> map of some kind and it needs three things.
>
> The style of the text node. We plan to do a proof-of-concept implementation
> with just inline and block. Later the semantic action file can provide this.
> The index position of the text node in the DOM.
> The range of character offsets this text node represents in the text view.
>
> When the XML is parsed, or after it is parsed by walking the DOM tree, we
> build the map or list of text nodes with the style and the index of each text
> node.
>
> To get the actual text, or braille for that matter, you can use XPath to
> extract the text from the text node at a given index.
> The style field of the item in the map tells the view how to format it on the
> screen.
>
> The view adds the text offsets to the map for each text node that is
> displayed as it does the rendering.
>
> When the text changes in the view the map is used to make those changes in
> the DOM. The document (DocumentBase) makes the changes and notifies the views
> through the DocumentManager to update.
>
> Inserting text (typing) is easy as we only need to change the content of the
> currently referenced text node.
>
> Deleteing is also easy if the text we are deleting is contained in a single
> text node.
>
> Things get a little more complicated if a node becomes empty, a two nodes are
> merged by a delete action, or a new node is created by an insertion.
> We also have to decide things like what happens when a text node becomes
> empty. Do we delete the parent element or just leave an empty element?
>
> Chuck is, in addition to working on the tool bar, going to do some research
> into whether there is an open-source widget that takes care of any of this.
> He's also going to poke around for something that can format text based on a
> style sheet (css). Either of these might be useful and shorten development
> time.
>
> Brandon is going to put together a proof-of-concept application that attempts
> to use the mapping scheme we talked about using the StyledTextView and an XOM
> DOM (how cute) to see if this idea will work. If the concept works then we
> are very close to having like a wisiwyg XML editor. The only restrictions is
> that it won't use mixed fonts initially and is pretty simple in its
> presentation.
>
>
>
>
>
>
>
>
> 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 24, 2013 12:23 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: What will the text view show?
>
> Hi Keith,
>
> Having the text view handle semantic-action files is an interesting idea.
> It's a matter of what is considered the best way to encapsulate things. My
> thought was that the document class would encapsulate knowledge about the
> vocabulary of the document and the text view would deal with an abstraction
> by calling methids in DocumentBase.
> Encapsulating this knowledge in the text view is another possibility.
>
> For the future, how will the browser view handle various tyoes of documents?
> I would think that an xsl stylesheet would be appropriate for xml documents.
> Are these available for diferent document types?
>
> John
>
> On Thu, Jan 24, 2013 at 01:52:37PM +0000, Keith Creasy wrote:
> > John.
> >
> > I view this as more of a mental exercise because as far as I know we've
> > decided to use your model, but...
> >
> > Why couldn't the text view and the braille view use the semantic action
> > file? If its purpose is to define how the text and braille get formatted in
> > the view then the view is where it belongs I think.
> >
> > No matter how we do it mapping text in the text view to nodes in the XML
> > document won't be simple. Yes, it will involve offsets and some kind of
> > mapper to map the text to its corresponding text node. I can't think of any
> > way around that.
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > Boyer
> > Sent: Thursday, January 24, 2013 8:38 AM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: What will the text view show?
> >
> > Hi Keith,
> >
> > I'm trying to understand your approach. Wouldn't the text view have to know
> > the vocabulary of the particular xml document? The Braille view will of
> > course use the UTDML vocabulary. The tree view essentially shows the
> > structure of the document, with element names, etc.
> >
> > On using XPath expressions to locate text nodes, the search for a text node
> > must start with the cursor location in the StyledText control. How is this
> > related to XPath?
> >
> > I can see that the text view might have different methods or embedded
> > classes for diferent document types, such as Daisy, epub3, heml5, etc.
> > This is similar to using semantic-action files, but more cumbbersome and
> > less flexible.
> >
> > John
> >
> > On Wed, Jan 23, 2013 at 05:45:47PM +0000, Keith Creasy wrote:
> > > OK, I'll try again to explain this.
> > >
> > > I've always thought the format of the text in the views should be
> > > controlled from within the views and that the view should just use the
> > > XML and do the formatting. Semantics might still come into play but
> > > anything that controls how the text or braille gets rendered on the
> > > medium, in this case the screen, gets done by the view or one of it's
> > > member objects.
> > >
> > >
> > > This keeps the view and the rendering process encapsulated.
> > >
> > > The procedure might look like this:
> > >
> > > 1. DocumentManager creates an instance of DocumentBase and the views
> > > associated with the document.
> > > 2. XML is opened and processed through LibLouisUTD to create the internal
> > > document model.
> > > 3. Once the document is parsed and the model is complete DocumentManager
> > > informs the views to perform an initial update.
> > > 4. Each view calls methods that access the document model to pull
> > > content, in the form of XML that has the UTDML markup included.
> > > 5. The view, or one of it's members, processes a segment of the XML in
> > > order to render content. In the case of the braille view, for example, it
> > > would get braille elements and create the formatted braille and add the
> > > newly formatted content to the StyledContent object and the view would
> > > display it.
> > >
> > >
> > > In this way any view gets it's content in the form of XML and knows what
> > > to do with it.
> > >
> > > Does it make any sense? Please ask questions if it isn't clear.
> > >
> > > 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: Wednesday, January 23, 2013 12:22 PM
> > > To: brailleblaster@xxxxxxxxxxxxx
> > > Subject: [brailleblaster] Re: What will the text view show?
> > >
> > > Hi Keith,
> > >
> > > Let me hear your approach, so it's a two-way street.
> > >
> > > John
> > >
> > > On Wed, Jan 23, 2013 at 04:53:58PM +0000, Keith Creasy wrote:
> > > > Hi John.
> > > >
> > > > Well, since I'd have used a different approach to most of this I guess
> > > > you are the driver here. What would you like? We are all anxious to see
> > > > how the views get the content they need to display and how it is linked
> > > > back to the elements in the XML.
> > > >
> > > >
> > > > We can even add an additional view if that's what folks want.
> > > >
> > > > 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: Wednesday, January 23, 2013 11:50 AM
> > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > Subject: [brailleblaster] What will the text view show?
> > > >
> > > > If I remember right, in the original spec what is now called the text
> > > > view would present an appearance like that of a simple word processor,
> > > > with paragraphs, headings, tables, etc. Alternatively, it could be
> > > > switched to show the original print for each line in the Braille view.
> > > > I would like to know the present "views" on this matter, so I know what
> > > > to develop in the document package.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > --
> > > > 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; 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; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
