jrbowden
jrbowden
Hi Bert, Michael, I have constructed the attached test file, using a fairly minimal set of rules extracted from the UEB tables. On the surface there seems nothing wrong with...
here is a YAML test that demonstrates the issue: // assume standard headers for forward translation tests: "['1a',⠼⠁⠰⠁⠻ # fails "['1b',⠼⠁⠰⠃] # passes I noticed in the UK table en-gb-g1.utb,...
Many thanks @bertfrees for the stripped down tests. I believe my PR #1509 fixes the first problem. The fix was to correctly define the semicolon; instead of the strange rules...
@bertfrees your suggestion of deleting the "digit" lines, does indeed solve this issue. However, it introduces a new one: when translating 1A an unwanted grade 1 indicator is added. Current...
Thanks @bertfrees that's helpful. OK, so I tried changing the ``digit`` lines to use "lower" numbers. This does fix the display of unknown characters. However, as soon as I change:...
Thanks @bertfrees your suggestion worked. I have so far now fixed three issues which arose from changing the ``digit`` characters. One still remains and your help appreciated: Back translating strings...
OK, thanks. yes, that seems to work, but I'm not a huge fan of putting basic things like numbers at the end :) OK, this issue should be fixed in...
I've noticed a problem with the suggested fix: If the output is Unicode braille, all is well, e.g.: ``` - "[\y1f60a, ⠳⠽⠂⠋⠖⠴⠁] ``` Success. But, if the output is ordinary...
Hi, I just looked at the UEB table and the problem is the opcode sufword. Some of the UEB rules use opcodes like word, sufword, and so on, while possibly...
So, to help me understand better, if I had a rule: sufword abc xyz How would I write this as an equivalent rule with match? match ???? abc ??? xyz...