[brailleblaster] Re: UTDML's markup for print pages
- From: Brandon Roller <brandon.r.roller@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Tue, 28 Jan 2014 13:40:40 -0500
Is there a setting I can use so that the text version isn't included?
Having the text version seems more trouble than it is worth because of the
hoops you end up jumping through. Again, I am not a fan of just calling
every element brl, even when the markup is different from the typical brl
element that represents translation of text. If I'm dealing with the brl
elements I end up having to do a lot of unnecessary checks to determine
what I am dealing with.
On Tue, Jan 28, 2014 at 1:06 PM, John J. Boyer <john.boyer@xxxxxxxxxxxxxxxxx
> wrote:
> Print page numbers and other things generated by the program are
> enclosed in span elements with a class="brlonly" attribute. These span
> elements occur inside <brl> elements. In turn they contain a generated
> text and a generated braille component, which is inside the span
> tat. This is done so that the application which is displaying the
> material will have both a text and a braille version to use without
> back-translation.
>
> John
>
> On Tue, Jan 28, 2014 at 11:02:51AM -0500, Brandon Roller wrote:
> > Why is the markup of a brl element for a print page different than other
> > brl elements? It's a brl element containing a span tag containing
> another
> > brl element. Shouldn't it just be a brl element with the braille
> > representation of a page number?
>
> --
> 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:
