[liblouis-liblouisxml] Re: Proposal for capital and emphasis in UEB
- From: "Christo de Klerk" <cjdk@xxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Wed, 28 Jan 2015 15:15:18 +0200
Hey again John
I will make some inquiries about a programming manual in UEB and see what I
can get you.
Well, you can feel good about what you have achieved.
Kind regards
Christo
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
Boyer
Sent: 28 January 2015 3:12 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis in UEB
Hi Christo,
I will be very interested to see the math handbook. Would it also be
possible to get a program listing?
Your support of liblouis is encouraging. I've more or less retired from
programming at age 78, so I'm glad to see younger and more vigorous people
taking up the torch.
John
On Wed, Jan 28, 2015 at 02:51:44PM +0200, Christo de Klerk wrote:
> Hello John
>
> You might want to look through the UEB Guidelines for Technical
> Material which you can find on the ICEB website:
>
> www.iceb.org
>
> and then taking the Unified English Braille link. I will see if I can
> get you a .brf of, say, a maths handbook in UEB.
>
> You have done a wonderful job with LibLouis and may your good work
continue.
> It will be something really great when blind users have the option of
> a free high quality braille translator for unified codes. I say
> "unified codes", because already there are many more languages which
> follow the principles of the UEB. In South Africa we talk of UBC,
> Unified Braille Code, instead of UEB, because all our languages, not
> just English, are unified. All codes are identical, except for the
> contractions for each language. It makes life a lot easier.
>
> It is true that Nemeth is quite a bit more compact than the technical
> component of the UEB, but when you look at it from the point of view
> of someone learning or teaching braille, it is just so much simpler to
> have one code where a symbol has the same meaning in any kind of
> document. A period is always a period; a parenthesis isn't sometimes a
> bracket; numbers are always the same. When you start learning
> technical material, you don't have to learn new representations for
> well-known symbols. I always think of the UEB as a vast toolbox; you
> use from it whatever you need and when you need something for a
> special case, look in the box, it is there. Yes, it requires a big
> change of mindset, but you can take it from me that in a country where
> we have been using unified codes for many years already, it makes life a
lot simpler.
>
> I will follow the LibLouis project's development with interest and
> enthusiasm. I would like to become involved in table development, but
> have not been able to find documentation to teach a dunce like me in
> baby steps how to get started. I have looked inside LibLouis tables,
> but they differ completely from what I know from the Duxbury tables.
>
> Kind regards
>
> Christo
>
>
> -----Original Message-----
> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> Boyer
> Sent: 28 January 2015 2:27 PM
> To: liblouis-liblouisxml@xxxxxxxxxxxxx
> Subject: [liblouis-liblouisxml] Re: Proposal for capital and emphasis
> in UEB
>
> 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
>
> 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
Other related posts:
