I am aware that no answer yet has been given to your original question.
Having done a bit more work using context and multipass opcodes for some
tables I am working on, they really seem to be questionable in how these
rules work and I feel just unreliable opcodes. The documentation is so
slim and there are so many cases beyond the documentation specification
one is reliant on undocumented and probably undefined behaviour, who
knows if it will change in the future without notice.
I think I now understand why Mike Gray decided to create the match
opcode to replace these. I am not sure if that match opcode has been
included into the standard liblouis or if it is still an APH specific
feature. I am not sure if he added details of the match opcode to the
documentation but here is a link to an old mailing list post where the
match opcode was described
//www.freelists.org/post/liblouis-liblouisxml/new-opcodes
Also here is a link to the issue for merging the documentation for the
match opcode https://github.com/liblouis/liblouis/pull/189/files
May be this will offer a possible solution.
Michael Whapples
On 02/01/2017 16:30, Dave Mielke wrote:
[quoted lines by Michael Whapples on 2017/01/02 at 10:38 +0000]
OK, I wasn't certain and now you mention getting repeated dots 56 forFor that case (empty brackets), lou_trace gives me:
that first rule I think I had a similar issue when creating a
different rule.
1. lowercase a 1
2. context `[]$w @56
3. lowercase a 1
4. context `[]$w @56
And so on. The log made it easier to count. It looped 256 times.
I have done a bit more looking at it and my original suggestion ofThis is what lou_trace gives for my original method (class name within
@56* was wrong, it appears that can be used in the third column. So
yes your original suggestion looks correct.
brackets, and @56*):
1. lowercase a 1
2. context `[$w] @56*
3. lowercase b 12
4. lowercase c 14
5. space 0
6. lowercase d 145
7. context _!$l[$w] @56*
8. lowercase e 15
9. lowercase f 124
