[liblouis-liblouisxml] Re: A new liblouis?
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sun, 27 Oct 2013 18:27:15 +0000
I will point out we do have an epub expert already on the list he is currently
on vacation but you will be hearing from Keith soon I am sure.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Susan Jolly
Sent: Sunday, October 27, 2013 2:22 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: A new liblouis?
Hi John G. and others,
I hope this will be considered civil.
You definitely need a lot of additional highly experienced software engineers.
This is not meant as a criticism of the current team but simply to underscore
the importance of the project. This need should be taken into consideration
before choosing a programming language.
Those of us who enjoy programming are always eager to jump into programming but
as you all well know, the actual programming is only a small part of a software
development project.
There are many technical issues to be considered prior to actual programming or
even choosing a language.
A major issue is the adoption of EPUB 3. Matt Garrish, one of its designers,
worked for CNIB for many years and his knowledge of the intricacies of braille
transcription informed the design of EPUB 3.
Designing braille software without a thorough understanding of EPUB 3 seems
silly to me. I strongly recommend reading the book "EPUB 3 Best Practices"
by Matt Garrish and Marcus Gylling.
Here is a list of three items where what I've done differently from liblouis
has been successful. I've added links where I've written more about an issue.
I'm glad to answer questions about individual items but my main point here is
to give some specific examples to underscore my contention that there is a lot
to think about before plunging forward.
(1) Translation tables for contracted braille systems typically contain two
types of rules. One type of translation rule is defined by the braille system.
For example, a certain contraction may be used in certain contexts.
The other type of rule is an ad hoc rule used to account for certain exceptions
to the default rules. There are several advantages to using some sort of extra
opcode or label so as to distinguish these two types.
http://www.dotlessbraille.org/bidissues2.htm#dotsys
(2) There are many situations where contracted braille systems only use a
subset of the default rules. For example, EBAE doesn't allow certain
contractions to be used in proper names. Also there are many systems of learner
braille or grade-relaxed braille based on using subsets of the default rules.
It is possible to design a single translation table with all the rules such
that an engine can easily extract the proper subsets.
http://www.dotlessbraille.org/BrailleTransSpec1.htm
(3) One of the unique problems with dealing with braille automatically is that
the same braille character or braille cell typically has multiple semantics.
This is, of course, a key reason why it is so difficult to automate accurate
back translation.
(As an aside, let me note that the only way to eliminate the backtranslation
problem would be to make braille more verbose which would of course be
ridiculous since it would make braille harder for humans to read. The only
effective way I know of to accurately backtranslate a particular braille system
is parsing which requires developing a lexer grammar specific to that
system.)
Given that the same braille cell has multiple semantics, is a direct
representation of braille cells the best internal data structure for braille?
We know from the success of Unicode the value of having a unique code point for
each unique character. However, braille cells differ from the majority of
characters because of their multiple semantics both within the same braille
system and in different systems. That's why I use what I call extended braille
where I assign a private code point not to each braille cell but to each
different semantics of a braille cell within a particular braille system. EBAE
requires several hundred code points; I don't know about other systems.
Susan
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:
