[brailleblaster] Re: What will the text view show?

  • From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
  • To: brailleblaster@xxxxxxxxxxxxx
  • Date: Thu, 24 Jan 2013 11:23:22 -0600

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


Other related posts: