[liblouis-liblouisxml] Re: Proposal for capital and emphasis in UEB
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Wed, 28 Jan 2015 06:27:00 -0600
Technical Braille is precisely what I am most interested in. I lost most
of my hearing at age eight, so I could not use readers. Shortly
thereafter I discovered my interest in sciencee. To my dismay, there was
very little good scientific material in Braille. This was in the 40s.
When I got to high school I found that my physics book was older than I
was. These early experiences made me determined to do what I could so
that others would not have them. Things have improved now, but the
amount of good technical material in Braille is still woefully
inadequate.
I designed liblouis and liblouisutdml from the start with special
features for mathematics. When it came to translating mMathML to
Braille, I was surprised at how easy it was to produce a Nemeth
translation. Producing a translation into UKMaths was much more
difficult and required the creation of a lot of new programmming code.
It would be nice to see some technical material in UEB, especially part
of a programming manual. So far, I have seen only the UEB rule book.
Now, on emphasis, liblouis certainly needs to handle emphasis in UEB.
That will also help with languages other than English, which have
similar rules. It is truly great that APH has assigned a programmer to
implement these rules.
I don't have a quarrel with the literary aspects of UEB. Many of the
contractions that have ben dropped shouldn't have been there in the
first place. Examples are the contractions for ble and o'clock. However,
Nemeth is a far superior method of representing mathematics than the
traditional method on which UEB math is based. Many programmers will
continue to use 8-dot Braille. It will probably remain one of the
choices in screenreaders.
Well, these are my opinions, based on my experience.
John
On Wed, Jan 28, 2015 at 10:23:39AM +0200, Christo de Klerk wrote:
> Hello John
>
> I will deal with some issues raised by you and also by Joseph.
>
> ICEB has a Braille Technology Committee of which I am the convenor and
> certainly we believe that it is always good, essential for an authority and
> users and software developers to communicate on an ongoing basis and we
> would be happy to establish such a channel.
>
> All English speaking countries which have adopted the UEB except for the US,
> use the integrated maths symbols and do not need to switch to Nemeth, so
> there is no need for any code transition. It works extremely well for those
> countries and we can only hope that the US will see the light soon.
>
> There is no need for what used to be "computer braille" in UEB. The code is
> comprehensive enough to represent any characters previously represented in
> computer braille. It would be no problem producing a complex computer manual
> in UEB and users actually find it much simpler to read technical material in
> UEB, because it is not necessary to learn different symbols for the
> different codes. There is thus no need for code switching to represent a
> piece of programming code. Things like e-mail addresses and URLs are written
> in UEB just as they come, no need to switch into another code.
>
> It is true that the UEB does not include an 8 dot code and the currently 8
> dot code can therefore still be used where it is required.
>
> When we developed the UEB, our brief was to develop a code which would be
> unified (in other words, no separate codes for different types of material),
> a code that would not tolerate any ambiguity and a code which would have as
> little as possible impact of readers of literary (non-technical) braille. I
> believe that we achieved all three those aims.
>
> The fact that the UEB does not tolerate ambiguity, means that back
> translation is actually simpler and more reliable than is the case with
> pre-unified braille. If you apply the principles of the UEB, neither man,
> nor machine could be in doubt as to the meaning. Because we focused on
> readability, understandability and ease of use, our approach has been that
> we would rather have machines and software adapt to the needs of users and
> have users adapt to the needs of machines.
>
> But we always did keep computability in mind. Throughout the development of
> the UEB Joe Sullivan of Duxbury played a leading role. Some of the new
> aspects of the code required substantial changes to the Duxbury system in
> order to handle them and now it does handle them perfectly. Because of the
> completely different way the UEB deals with capitalisation and typeform
> indicators, similar fundamental code changes will no doubt required from
> LibLouis also. It will be a major undertaking, but it can be done, just like
> it has been done in Duxbury.
>
> Just some background information about myself, so that you can understand
> the position from which I am talking: I have worked as a computer programmer
> for over 30 years. I have been doing Duxbury table development and
> maintenance since 1986. In my opinion the UEB lends itself much more readily
> to automated translation and back translation than does pre-unified code,
> but it will require substantial work to LibLouis to accommodate these new
> developments. I believe these new ways of doing things have come to stay, as
> they have been embraced with enthusiasm and implemented already in many
> countries. In South Africa we have applied the principles of the UEB to all
> 11 our official languages. In New Zealand they have done likewise with the
> Maori language. Many code manuals have already been written about the UEB.
> The bottom line is that I believe the position is that the software should
> be adapted to accommodate the code and not the other way around. Having just
> implemented the code across the world it would be a major disruption for
> users if fundamental changes were to be made to it again. We have just
> overcome a wave of major resistance; we don't need another <smile>.
>
> But please, let us keep in regular touch. From ICEB's side we strongly
> encourage the LibLouis project. There is a worldwide need for it, especially
> so in developing countries.
>
> Kind regards
>
> Christo de Klerk
>
> -----Original Message-----
> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> Boyer
> Sent: 28 January 2015 4:28 AM
> To: liblouis-liblouisxml@xxxxxxxxxxxxx
> Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis in UEB
>
> One thing I've been wondering about is that UEB has no computer Braille.
> How are programs supposed to be dshown? What about 8-dot Braille?
> That is very convenient for viewing programs on a Braille display. I also
> thought that UEB would get rid of some things that made back-translation
> dificult.
>
> John
>
> On Wed, Jan 28, 2015 at 12:37:43AM +0000, Keith Creasy wrote:
> > Thank you Joseph. I just want to say that I agree that close dialog
> between braille authorities and software developers would be very beneficial
> to the future of braille and UEB in particular. That has been on my mind a
> lot lately.
> >
> > Keith
> >
> >
> > -----Original Message-----
> > From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> > [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Joseph
> > Lee
> > Sent: Tuesday, January 27, 2015 3:28 PM
> > To: liblouis-liblouisxml@xxxxxxxxxxxxx
> > Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis
> > in UEB
> >
> > Hi Christo,
> > As one of the LibLouis table maintainers for Unified English Braille, I do
> know how rewarding it is to introduce UEB to LibLouis users and developers
> around the world. However, throughout the course of UEB table development, I
> and others here felt that there are certain things in UEB itself that may
> need to be modified for programs such as LibLouis to take advantage of it.
> > Some of my own concerns include smoother transition between literary
> > and math, certain rules that causes back translation problems and so
> > on. In short, some of us here felt that UEB's emphasis in heuristic
> > transcription practices (that is, human transcribers deciding what to
> > do with forward and back translation issues based on formal rules) may
> > have caused issues when computer programs are tasked to "transcribe"
> > (forward and back translate) text into UEB. Thus I and others
> > (especially those of us with programming
> > background) would like to suggest having a regular dialogue between us and
> ICEB/UEB committee in hopes of making UEB friendly towards both humans and
> computers.
> > Thanks, and I hope best of luck to you and ICEB.
> > Cheers,
> > Joseph
> >
> > -----Original Message-----
> > From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> > [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
> > Christo de Klerk
> > Sent: Tuesday, January 27, 2015 9:15 AM
> > To: liblouis-liblouisxml@xxxxxxxxxxxxx
> > Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis
> > in UEB
> >
> > Hello all
> >
> > On behalf of the International Council on English Braille (ICEB) I wish to
> say that we are extremely pleased about this development. It is essential
> that LibLouis must make provision for these aspects of the UEB.
> >
> > We wish the developer every success with this endeavour.
> >
> > Kind regards
> >
> > Christo de Klerk - President: International Council on English Braille
> >
> > -----Original Message-----
> > From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> > [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > Boyer
> > Sent: 27 January 2015 6:49 PM
> > To: liblouis-liblouisxml@xxxxxxxxxxxxx
> > Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis
> > in UEB
> >
> > Hi Keith,
> >
> > This sounds good. I will give whatever help I can.
> >
> > John
> >
> > On Tue, Jan 27, 2015 at 03:41:16PM +0000, Keith Creasy wrote:
> > > Dear all.
> > >
> > > We at APH are working on a project to create high-quality braille
> > > from
> > publisher's files to be embossed using the new BANA UEB specifications.
> > LibLouis currently has a few shortcomings that need to be addressed before
> we can achieve the quality output we need. A couple of these have already
> been partially implemented by us or others.
> > >
> > >
> > >
> > > 1. Capitalization of phrases. Addition of cap-phrase sign and end
> > cap-phrase sign along with implementation to support it.
> > >
> > > 2. Correct UEB capitalization within words with mixed case.
> > >
> > > 3. Correct application of symbols to begin and end emphasis
> > (typeforms).
> > >
> > > 4. Support for additional, custom, typeforms provided by UEB.
> > >
> > >
> > > We are proposing doing this coding ourselves. Along with some
> > > corrections
> > to the tables, with deference to the work Joseph and Ken are doing on UEB
> tables.
> > >
> > >
> > > One of the main changes we'd like to make is to change the way
> > capitalization is handled so that internally LibLouis simply treats it as
> another form of emphasis. The only differences being that the attributes
> used for the capitalization is inherent in the text and does not need to be
> passed in as an argument when translating, and of course LibLouis handles
> capitalization in reverse as well as forward translation.
> > >
> > >
> > > Internally there is actually even less difference between emphasis
> > (typeforms) and how we hope to handle capitalization. Our plan is to
> expand the values used in the array that indicates emphasis and, on the
> first pass LibLouis makes through the text, set the array for capital
> emphasis at that time. Then handle it along with all other forms of
> emphasis.
> > >
> > >
> > > In order to handle cases where we have multiple emphasis or
> > > typeforms the
> > current implementation needs to be enhanced so that it not only knows when
> the emphasis flags change but exactly how they change. This is in fact the
> only way to make capitalization as a form of emphasis work. An additional
> benefit of this is of course handling mixed bold, italics, and underlined
> text even if they are irregularly mixed.
> > >
> > >
> > > I know it is usually preferable to make changes in very small
> > > increments
> > but we don't see a way to do this for our purposes. We plan to fork
> LibLouis, work on and test it while keeping in sync with the master LibLouis
> code as we can, and then at some point work on merging our work back to the
> master repository if that is desirable.
> > >
> > > Mike Gray mgray@xxxxxxx<mailto:mgray@xxxxxxx> is the programmer we
> > > have tasked with accomplishing this work. We welcome any feedback.
> > > It is our hope to improve LibLouis for eve
> > >
> > > Regards,
> > > Keith Creasy
> > > ryone
> >
> > --
> > John J. Boyer; President,
> > Abilitiessoft, Inc.
> > http://www.abilitiessoft.com
> > Madison, Wisconsin USA
> > Developing software for people with disabilities
> >
> > For a description of the software, to download it and links to project
> > pages go to http://www.abilitiessoft.com
> >
> > For a description of the software, to download it and links to project
> > pages go to http://www.abilitiessoft.com
> >
> > For a description of the software, to download it and links to project
> > pages go to http://www.abilitiessoft.com For a description of the
> > software, to download it and links to project pages go to
> > http://www.abilitiessoft.com
>
> --
> John J. Boyer; President,
> Abilitiessoft, Inc.
> http://www.abilitiessoft.com
> Madison, Wisconsin USA
> Developing software for people with disabilities
>
> For a description of the software, to download it and links to project pages
> go to http://www.abilitiessoft.com
>
> For a description of the software, to download it and links to
> project pages go to http://www.abilitiessoft.com
--
John J. Boyer; President,
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
