[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 10:23:39 +0200
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
Other related posts:
