Hi John Sorry for the long delay, but, but it took me a while to get hold of some computer related material in UEB for you, but I have now attached this module which deals with: HTML attributes Creating a website Create lists Please keep in mind that I got this straight from the datatypist and that it has not been proofread yet, but even that is a plus for UEB, being able to produce a good even though unproofread copy. 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
Attachment:
Module 6.2.brf
Description: Binary data
