[liblouis-liblouisxml] Re: Regex question
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sun, 27 Oct 2013 18:25:03 +0000
I think you miss understood I do not want to get rid of the table system. I
just want a new opp code for regex. I have found something's like multiple
dashs and even 's that could be easily matched with regex and is more difficult
with some of the context tests now. So all I was saying is it would be nice to
have a full regex opp code and an action that operated on the matched regex
groupings.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Susan Jolly
Sent: Sunday, October 27, 2013 11:45 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Regex question
We still aren't communicating. The immediate problem isn't how to implement an
action within the engine. The problem is how the person responsible for
maintaining the translation table for a particular braille system can define a
special action and the conditions under which it applies.
Since liblouis handles a large number of different braille systems, it's been
possible to discover that there are many special cases that can be handled by
the same simple action if the action is parameterized. The various actions are
built into the engine but there needs to be a way for the table maintainer to
specify the parameters. If I'm understanding correctly, John Boyer is
suggesting a way for the maintainer to specify a particular action plus its
parameters. In my opinion the details of the specification should be
independent of the method by which the conditions and action are actually
implemented in the engine. For example, it isn't necessary that the
specification use a regex even if use of a regex were to turn out to be the
best way to implement the rule within the engine.
I've worked primarily with EBAE but I've encountered some complex special rules
that don't seem amenable to the above approach. In these case I've fully
implemented the rule, both the conditions and the action, in the engine. An
example is the EBAE rule for stammered words that prohibits the use of any
contractions directly involved in the stammer. Thus in the stammer g-g-ghost
the first (gh) contraction is not used but the second (st) one is. This is a
case where the conditions for using the rule require rather complex built-in
heuristics for determining whether or not a word is a stammer.
I've given all these fully implemented special rules identifiers that can be
referenced in a translation table so as to activate the desired rules.
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:
