[liblouis-liblouisxml] Re: Code priorities for liblouis and liblouisutdml
- From: Joseph Lee <joseph.lee22590@xxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Fri, 04 Oct 2013 14:16:27 -0700
Hi all,
From what I can see from recent commits and by examining the UEB
rule book, it seems that we need some overhaul of both existing
tables and code, such as utilizble undocumented opcodes.
The issues are as follows:
* Accents: These are proceeded by the type of accent before the
letter itself. Luckily, the uppercase version can be written
with dot 6 in front of accent marks. So for these, short-term
solution is to write all accented letter combos via uplow opcode.
* Elimination of computer braille: There's no need for computer
braille at all. However, since the current UEB implementation is
based on UddS. braille, a good solution is to merge UEB grade 1
and character definitions into a single table. This can be done
in a number of ways, including moving chardefs to grade 1 or
using character definitions to store Unicode UEB symbols,
punctuation, accents and so on and to use grade 1 to store G1
specific rules such as letter signs.
* When to contract and when not to: there are rules in UEB where
certain contractions are valid in some rules but are illegal.
This includes cases such as a number followed by a word which
contains a contraction (with that, the word itself should not be
contracted), a vowel following a contraction (for example,
"dayan" which should not be contracted, otherwise we get dot 5,
then "dan") and other cases.
I think the most effective solution is C-based regexp opcode to
catch cases like the ones described above. This should also help
with simplifying some tables by using patterns. Also, the best
people who can give us feedback are UEB users and transcribers
(such as Leona) who knows the inner workings behind UEB. Lastly,
I believe we need some UI mechanisms in software which uses UEB
(such as NVDA) to omit computer braille usage when certain tables
are selected such as the UEB table set.
Thanks.
Cheers,
Joseph
----- Original Message -----
From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Date sent: Fri, 4 Oct 2013 12:22:32 -0500
Subject: [liblouis-liblouisxml] Re: Code priorities for liblouis
and liblouisutdml
Thanks. However, we have to sort out which of the problems are
due to
the tables and which require work on the code. The punctuation
problems
are very likely due to the tables. The capitalization problems
may
require the introduction of new rules.
John
On Fri, Oct 04, 2013 at 11:24:23AM +0000, Ken Perry wrote:
I think Joseph and Meiser understand what a lot of the problems
are. There are still lots of problems with the wrong punctuation
being used I also had sent a page and if you search back in the
emails you will find it that had more than half of the new
examples of UEB still not working. Here is the page again:
http://www.brailleauthority.org/ueb/overview_changes_ebae_ueb.htm
l
Just looking at {}, (), [], things like * and the others on the
punctuation table there are an amazing amount of them not
working. Not only that but there are dot 7's still in the table.
Next in the capitalization rule it says that after a dash the a
double capitalization mark is canceled so the following is broken
THIS-is-broke
The back translation of the previous make all words capitalized
and it adds spaces around the dashes.
The following is also broken triple capitalization mark which is
supposed to mark a phraze that has 3 or more words doesn't work
in our tables and I am not sure if it is a table problem I think
it might be the parser.
Example:
THIS IS BROKEN AS WELL
I have not yet tested the double 56 and triple 56 but I will and
see what happens.
My point is it is broken and users notice immediately when they
try to use it.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
John J. Boyer
Sent: Friday, October 04, 2013 6:42 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Code priorities for liblouis
and liblouisutdml
Ken,
Please specify just what you mean by full support of UEB.
Specifics are needed by those who do implementations.
The googlecode project pages already have a bug tracker.
John
On Fri, Oct 04, 2013 at 10:30:08AM +0000, Ken Perry wrote:
I think one is the full support of UEB by Liblouis. The second
might be a bug tracking system for liblouis so open source folks
can easily track problems and help fix them. If we had a bug
tracking system like bugzillia or rt we could also put tickets in
for creation of documents as well which would help coders like
myself know what needs to be done.
Once you get this list you are asking for compiled it might be
nice to divide it up and plan each of the next releases by
grouping the changes for each release for example if the most
important thing is full support of UEB then all resources should
go to that and the next release would support UEB along with any
small bug fixes that also were fixed.
I guess what I am suggesting is a feature based release schedule
in the future.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
John
J. Boyer
Sent: Friday, October 04, 2013 5:53 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Code priorities for liblouis and
liblouisutdml
The utd2brf.c module seems to be functioning properly. This is
good for future developmennt, because other modules which convert
utd to various forms, such as utd2volumes.c will use much of its
code. Further bugs will probably be in the underlying utd code.
For example, something has to be done about things like some URLs
that are too long to fit on a line. Intrducing a hyphenation
symbol would mess up endexing. I would like to know what people
consider the highest priority things for the liblouis and
liblouisutdml code.
Of course we also need better documentation. And we need
tutorials.
John
--
John J. Boyer; President, Chief Software Developer
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, Chief Software Developer
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, Chief Software Developer
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:
