In louis-rs, tests/braille-specs/hu-hu-g1_dictionary_special_consonants.yaml produce lot of capsletter and begcapsword, and few numsign indicators related failures

[hammera]

Hi Chris,

I commented out the line 93 temporary the tables/hu-hu-g1_braille_input.cti file, and looked what output produce the louis check tests/braille-specs/hu-hu-g1_dictionary_special_consonants.yaml command.
Usual, have lot of back-translation failures the capsletter indicator and begcapsword related indicators, the capsletter indicator in hu-hu-g1.ctb table are lust-rs back-translated with $ character, the begcapsword indicator are back-translated with two $ characters.
looks following examples:

1. A forward translation failure, with works right In Liblouis:
   Original word:
   9-sz-7760
   Right Liblouis unicode Braille:
   ⠼⠊⠤⠱⠤⠼⠛⠛⠋⠚
   Wrong louis-rs produced braille:
   ⠼⠪⠤⠱⠤⠼⠻⠻⠫⠬
   So, this output forward direction louis-rs marks all numbers with eight dot characters (not six dot combinations the litdigit opcode), and after the first hiphen character marks the numbers with eight dot variant, not six dot variant.
   Looks what happening in Liblouis if I use for example the lou_trace unicode.dis,hu-hu-g1.ctb command with forward direction, and paste the original input text:

root@hammera-pc:/mnt/@/vagrant# lou_trace unicode.dis,hu-hu-g1.ctb
9-sz-7760
⠼⠊⠤⠱⠤⠼⠛⠛⠋⠚
1.	litdigit	9	24
2.	hyphen	-	36
3.	always	sz	156
4.	hyphen	-	36
5.	litdigit	7	1245
6.	litdigit	7	1245
7.	litdigit	6	124
8.	litdigit	0	245

Look what happening if I back-translating the correct Braille output in lou_trace the original liblouis the -b option with lou_trace -b unicode.dis,hu-hu-g1.ctb command:

root@hammera-pc:/mnt/@# lou_trace -b unicode.dis,hu-hu-g1.ctb
⠼⠊⠤⠱⠤⠼⠛⠛⠋⠚
9-sz-7760
1.	numsign		3456
2.	litdigit	9	24
3.	hyphen	-	36
4.	endnum	sz	156
5.	hyphen	-	36
6.	numsign		3456
7.	litdigit	7	1245
8.	litdigit	7	1245
9.	litdigit	6	124
10.	litdigit	0	245

2. Original word: 9-Sz-7760
   Right unicode Braille in Liblouis:
   ⠼⠊⠤⠨⠱⠤⠼⠛⠛⠋⠚
   Wrong louis-rs unicode Braille:
   ⠼⠪⠤⠨⠎⠣⠤⠼⠻⠻⠫⠬"
   lou_trace unicode.dis,hu-hu-g1.ctb result:

root@hammera-pc:/mnt/@# lou_trace unicode.dis,hu-hu-g1.ctb
9-Sz-7760
⠼⠊⠤⠨⠱⠤⠼⠛⠛⠋⠚
1.	litdigit	9	24
2.	hyphen	-	36
3.	always	sz	156
4.	hyphen	-	36
5.	litdigit	7	1245
6.	litdigit	7	1245
7.	litdigit	6	124
8.	litdigit	0	245

lou_trace -b unicode.dis,hu-hu-g1.ctb command result:

root@hammera-pc:/mnt/@# lou_trace unicode.dis,hu-hu-g1.ctb -b
⠼⠊⠤⠨⠱⠤⠼⠛⠛⠋⠚
9-Sz-7760
1.	numsign		3456
2.	litdigit	9	24
3.	hyphen	-	36
4.	capsletter		46
5.	postpunc	sz	156
6.	hyphen	-	36
7.	numsign		3456
8.	litdigit	7	1245
9.	litdigit	7	1245
10.	litdigit	6	124
11.	litdigit	0	245

3. Look what happens for example with the begcapsword mixed numsign testcase:
   Input word: 9-SZ-7760
   Right unicode braille in Liblouis:
   ⠼⠊⠤⠨⠨⠱⠤⠼⠛⠛⠋⠚
   Wrong louis-rs unicode Braille:
   ⠼⠪⠤⠨⠨⠎⠣⠤⠼⠻⠻⠫⠬
   Look what happens in Liblouis when I run lou_trace unicode.dis,hu-hu-g1.ctb file:

root@hammera-pc:/mnt/@# lou_trace unicode.dis,hu-hu-g1.ctb
9-SZ-7760
⠼⠊⠤⠨⠨⠱⠤⠼⠛⠛⠋⠚
1.	litdigit	9	24
2.	hyphen	-	36
3.	always	sz	156
4.	hyphen	-	36
5.	litdigit	7	1245
6.	litdigit	7	1245
7.	litdigit	6	124
8.	litdigit	0	245

Looks what happen if I back-translate the right unicode Braille output (I ran simple the lou_trace -b unicode.dis,hu-hu-g1.ctb command, and pasted the right Braille input):

root@hammera-pc:/mnt/@# lou_trace unicode.dis,hu-hu-g1.ctb -b
⠼⠊⠤⠨⠨⠱⠤⠼⠛⠛⠋⠚
9-SZ-7760
1.	numsign		3456
2.	litdigit	9	24
3.	hyphen	-	36
4.	begcapsword		46-46
5.	postpunc	sz	156
6.	hyphen	-	36
7.	numsign		3456
8.	litdigit	7	1245
9.	litdigit	7	1245
10.	litdigit	6	124
11.	litdigit	0	245

4. A simple word failure with not contains capsletter indicator:

Failure { input: "⠁⠃⠕⠗⠞⠥⠱⠱⠁⠃⠈⠸⠕⠣⠈⠎⠞", expected: "abortuszszabályozást", actual: "abortuszszabá\u{7f}ozást", direction: Backward }

The tables/hu-chardefs.cti file are defined the dots 456 combination with the \x007f character:
letter \x007f 456
Looks what happens if I back-translate the right unicode Braille in Liblouis:

root@hammera-pc:/usr/src/liblouis/tables# lou_trace unicode.dis,hu-hu-g1.ctb -b
⠁⠃⠕⠗⠞⠥⠱⠱⠁⠃⠈⠸⠕⠣⠈⠎⠞
abortuszszabályozást
1.	lowercase	a	1
2.	lowercase	b	12
3.	lowercase	o	135
4.	lowercase	r	1235
5.	lowercase	t	2345
6.	lowercase	u	136
7.	always	ssz	156-156
8.	lowercase	a	1
9.	lowercase	b	12
10.	lowercase	á	4
11.	always	ly	456
12.	lowercase	o	135
13.	lowercase	z	126
14.	lowercase	á	4
15.	lowercase	s	234
16.	lowercase	t	2345
17.	correct	"bortusszab"	"bortuszszab"

So, the louis-rs binary replaces the ly character with \u{7f} sequence, independent to defined into the hu-chardefs.cti file the letter \x007f character with 456 dot combination, and defined the always ly 456 rule.
I attach entire test log with produces the tested harness file. Now me not opened the Rust prepared virtual machine with contains the installed louis-rs project, but if need, I welcome execute required test this four wrote examples.
test_dictionary.txt

Hopefully this issue help you the development,

Attila

[hammera]

Chris, I doed required tracing tests the four examples related (final installed my local system the louis-rs project after installed entire rustup project with Rust website:
The 9-sz-7760 word forward translation result with louis translate --tracing hu-hu-g1.ctb command, My assumption was correct in the first comment when I first read the louis-rs testcase failure, real louis-rs skyp the litdigit opcode:

> ⠼⠪⠤⠱⠤⠼⠻⠻⠫⠬
┌───┬──────┬────┬─────────────────┬───────┐
│   │ From │ To │ Rule            │ Stage │
├───┼──────┼────┼─────────────────┼───────┤
│ 0 │      │ ⠼  │ numsign ⠼       │ Main  │
│ 1 │ 9    │ ⠪  │ digit 9 ⠪       │ Main  │
│ 2 │ -    │ ⠤  │ punctuation - ⠤ │ Main  │
│ 3 │ sz   │ ⠱  │ always sz ⠱     │ Main  │
│ 4 │ -    │ ⠤  │ punctuation - ⠤ │ Main  │
│ 5 │      │ ⠼  │ numsign ⠼       │ Main  │
│ 6 │ 7    │ ⠻  │ digit 7 ⠻       │ Main  │
│ 7 │ 7    │ ⠻  │ digit 7 ⠻       │ Main  │
│ 8 │ 6    │ ⠫  │ digit 6 ⠫       │ Main  │
│ 9 │ 0    │ ⠬  │ digit 0 ⠬       │ Main  │
└───┴──────┴────┴─────────────────┴───────┘

The 9-Sz-7760 word result the same command, this is the simple capsletter word example when contains number the example:

> ⠼⠪⠤⠨⠎⠣⠤⠼⠻⠻⠫⠬
┌────┬──────┬────┬────────────────────┬───────┐
│    │ From │ To │ Rule               │ Stage │
├────┼──────┼────┼────────────────────┼───────┤
│ 0  │      │ ⠼  │ numsign ⠼          │ Main  │
│ 1  │ 9    │ ⠪  │ digit 9 ⠪          │ Main  │
│ 2  │ -    │ ⠤  │ punctuation - ⠤    │ Main  │
│ 3  │      │ ⠨  │ capsletter ⠨       │ Main  │
│ 4  │ S    │ ⠎  │ base uppercase S s │ Main  │
│ 5  │ z    │ ⠣  │ lowercase z ⠣      │ Main  │
│ 6  │ -    │ ⠤  │ punctuation - ⠤    │ Main  │
│ 7  │      │ ⠼  │ numsign ⠼          │ Main  │
│ 8  │ 7    │ ⠻  │ digit 7 ⠻          │ Main  │
│ 9  │ 7    │ ⠻  │ digit 7 ⠻          │ Main  │
│ 10 │ 6    │ ⠫  │ digit 6 ⠫          │ Main  │
│ 11 │ 0    │ ⠬  │ digit 0 ⠬          │ Main  │
└────┴──────┴────┴────────────────────┴───────┘

You see, louis-rs apply wrong rules when trying translate the uppercase hungarian sz letter.
Liblouis after the first hyphen character this example translate the Sz text part with always sz 156 opcode, and before the 156 opcode, simple put the capsletter dot 46 combination indicator.
Look same word with Liblouis the lou_trace unicode.dis,hu-hu-g1.ctb command, I show the result:

root@hammera-pc:/usr/src/liblouis# lou_trace unicode.dis,hu-hu-g1.ctb
9-Sz-7760
⠼⠊⠤⠨⠱⠤⠼⠛⠛⠋⠚
1.	litdigit	9	24
2.	hyphen	-	36
3.	always	sz	156
4.	hyphen	-	36
5.	litdigit	7	1245
6.	litdigit	7	1245
7.	litdigit	6	124
8.	litdigit	0	245

The uppercase example result in louis-rs project translation, example word is 9-SZ-7760 word.
I simple used the louis translate hu-hu-g1.ctb --tracing command:

> ⠼⠪⠤⠨⠨⠎⠣⠤⠼⠻⠻⠫⠬
┌────┬──────┬────┬────────────────────┬───────┐
│    │ From │ To │ Rule               │ Stage │
├────┼──────┼────┼────────────────────┼───────┤
│ 0  │      │ ⠼  │ numsign ⠼          │ Main  │
│ 1  │ 9    │ ⠪  │ digit 9 ⠪          │ Main  │
│ 2  │ -    │ ⠤  │ punctuation - ⠤    │ Main  │
│ 3  │      │ ⠨⠨ │ begcapsword ⠨⠨     │ Main  │
│ 4  │ S    │ ⠎  │ base uppercase S s │ Main  │
│ 5  │ Z    │ ⠣  │ base uppercase Z z │ Main  │
│ 6  │ -    │ ⠤  │ punctuation - ⠤    │ Main  │
│ 7  │      │ ⠼  │ numsign ⠼          │ Main  │
│ 8  │ 7    │ ⠻  │ digit 7 ⠻          │ Main  │
│ 9  │ 7    │ ⠻  │ digit 7 ⠻          │ Main  │
│ 10 │ 6    │ ⠫  │ digit 6 ⠫          │ Main  │
│ 11 │ 0    │ ⠬  │ digit 0 ⠬          │ Main  │
└────┴──────┴────┴────────────────────┴───────┘
> 

You see, louis-rs marks numbers with digit, not litdigit opcode, translate the sz allcaps word part with single uppercase letters (s and z letter), not the Liblouis used always operator code.
Right Liblouis result this example related the forward direction:

root@hammera-pc:/usr/src/liblouis# lou_trace unicode.dis,hu-hu-g1.ctb
9-SZ-7760
⠼⠊⠤⠨⠨⠱⠤⠼⠛⠛⠋⠚
1.	litdigit	9	24
2.	hyphen	-	36
3.	always	sz	156
4.	hyphen	-	36
5.	litdigit	7	1245
6.	litdigit	7	1245
7.	litdigit	6	124
8.	litdigit	0	245

The abortuszszabályozást forward translation is good in louis-rs, look the result:

> ⠁⠃⠕⠗⠞⠥⠱⠱⠁⠃⠈⠸⠕⠣⠈⠎⠞
┌────┬──────┬─────┬─────────────────┬───────┐
│    │ From │ To  │ Rule            │ Stage │
├────┼──────┼─────┼─────────────────┼───────┤
│ 0  │ a    │ ⠁   │ lowercase a ⠁   │ Main  │
│ 1  │ b    │ ⠃   │ lowercase b ⠃   │ Main  │
│ 2  │ o    │ ⠕   │ lowercase o ⠕   │ Main  │
│ 3  │ r    │ ⠗   │ lowercase r ⠗   │ Main  │
│ 4  │ t    │ ⠞   │ lowercase t ⠞   │ Main  │
│ 5  │ u    │ ⠥   │ lowercase u ⠥   │ Main  │
│ 6  │ szsz │ ⠱⠐⠱ │ always szsz ⠱⠐⠱ │ Main  │
│ 7  │ a    │ ⠁   │ lowercase a ⠁   │ Main  │
│ 8  │ b    │ ⠃   │ lowercase b ⠃   │ Main  │
│ 9  │ á    │ ⠈   │ lowercase á ⠈   │ Main  │
│ 10 │ ly   │ ⠸   │ always ly ⠸     │ Main  │
│ 11 │ o    │ ⠕   │ lowercase o ⠕   │ Main  │
│ 12 │ z    │ ⠣   │ lowercase z ⠣   │ Main  │
│ 13 │ á    │ ⠈   │ lowercase á ⠈   │ Main  │
│ 14 │ s    │ ⠎   │ lowercase s ⠎   │ Main  │
│ 15 │ t    │ ⠞   │ lowercase t ⠞   │ Main  │
└────┴──────┴─────┴─────────────────┴───────┘
┌───┬──────┬────┬───────────────┬───────┐
│   │ From │ To │ Rule          │ Stage │
├───┼──────┼────┼───────────────┼───────┤
│ 0 │ ⠱⠐⠱  │ ⠱⠱ │ pass2 @⠱⠐⠱ ⠱⠱ │ Pass2 │
└───┴──────┴────┴───────────────┴───────┘
> 

But the backward translation the braille output is not good (replaced the ly word the Rust implementation with 7f character), happens following when I use louis translate hu-hu-g1.ctb -d backward --tracing command:

> abortuszszabá�ozást
┌────┬──────┬─────┬───────────────┬───────┐
│    │ From │ To  │ Rule          │ Stage │
├────┼──────┼─────┼───────────────┼───────┤
│ 0  │ ⠁    │ a   │ lowercase a ⠁ │ Main  │
│ 1  │ ⠃    │ b   │ lowercase b ⠃ │ Main  │
│ 2  │ ⠕    │ o   │ lowercase o ⠕ │ Main  │
│ 3  │ ⠗    │ r   │ lowercase r ⠗ │ Main  │
│ 4  │ ⠞    │ t   │ lowercase t ⠞ │ Main  │
│ 5  │ ⠥    │ u   │ lowercase u ⠥ │ Main  │
│ 6  │ ⠱⠱   │ ssz │ always ssz ⠱⠱ │ Main  │
│ 7  │ ⠁    │ a   │ lowercase a ⠁ │ Main  │
│ 8  │ ⠃    │ b   │ lowercase b ⠃ │ Main  │
│ 9  │ ⠈    │ á   │ lowercase á ⠈ │ Main  │
│ 10 │ ⠸    │ �   │ letter � ⠸    │ Main  │
│ 11 │ ⠕    │ o   │ lowercase o ⠕ │ Main  │
│ 12 │ ⠣    │ z   │ lowercase z ⠣ │ Main  │
│ 13 │ ⠈    │ á   │ lowercase á ⠈ │ Main  │
│ 14 │ ⠎    │ s   │ lowercase s ⠎ │ Main  │
│ 15 │ ⠞    │ t   │ lowercase t ⠞ │ Main  │
└────┴──────┴─────┴───────────────┴───────┘
┌───┬────────────┬─────────────┬──────────────────────────────────┬───────┐
│   │ From       │ To          │ Rule                             │ Stage │
├───┼────────────┼─────────────┼──────────────────────────────────┼───────┤
│ 0 │ bortusszab │ bortuszszab │ correct "bortusszab" bortuszszab │ Pre   │
└───┴────────────┴─────────────┴──────────────────────────────────┴───────┘
> 

Looks this abortuszszabályozást hungarian word how back-translate the Liblouis original implementation:

root@hammera-pc:/usr/src/liblouis# lou_trace unicode.dis,hu-hu-g1.ctb -b
⠁⠃⠕⠗⠞⠥⠱⠱⠁⠃⠈⠸⠕⠣⠈⠎⠞
abortuszszabályozást
1.	lowercase	a	1
2.	lowercase	b	12
3.	lowercase	o	135
4.	lowercase	r	1235
5.	lowercase	t	2345
6.	lowercase	u	136
7.	always	ssz	156-156
8.	lowercase	a	1
9.	lowercase	b	12
10.	lowercase	á	4
11.	always	ly	456
12.	lowercase	o	135
13.	lowercase	z	126
14.	lowercase	á	4
15.	lowercase	s	234
16.	lowercase	t	2345
17.	correct	"bortusszab"	"bortuszszab"

Hopefully this louis-rs tracing informations is help you the implementation related development,

Attila

[hammera]

There's one thing I don't understand about louis-rs. In the tables folder of the Liblouis source, I used the grep "include digit" hu* command to check which tables and subtables now contain include operations related to numbers:

hu-chardefs.cti:include digits6DotsPlusDot6.uti
hu-hu-comp8.ctb:include digits6DotsPlusDot6.uti

The hu-hu-comp8.ctb table is not relevant this numbers related testcase examples with the louis-rs project related.
The hu-chardefs.cti file are included with following tables and subtables:

hu-hu-g1.ctb:include hu-chardefs.cti (into the 28. line have this include line)
hu-hu-g2.ctb:include hu-chardefs.cti (into the 45. line)

The litdigit operator codes are defined with following table or subtable files a correct simple include line (grep litdigit hu* command result):

hu-hu-g1.ctb:include litdigits6Dots.uti (line number into hu-hu-g1.ctb: 52. line, so after the hu-chardefs.cti include line)
hu-hu-g2.ctb:include litdigits6Dots.uti (line number into the table to include litdigit 6 dot table is 68, so the include correct happens after the hu-chardefs.cti file include).

In the traditional original Liblouis, the precedence order works fine, and in both cases 1-sz-1, 1-Sz-1, 1-SZ-1, Liblouis displays the numbers with the litdigit operator code in the hu-hu-g1.ctb and hu-hu-g2.ctb tables, in six-dot Braille format, as it should.
In contrast, it seems that louis-rs stops at the include digits6DotsPlusDot6.uti operation performed in the hu-chardefs.cti file, and displays the numbers with the digit operator code in these test cases (as you saw in the tracing output yesterday), the include operation of the litdigit 6-dot tables in the listed rows in the hu-hu-g1.ctb and hu-hu-g2.ctb tables does not take effect, at least that's what I concluded.
If I just type the number 1 in the louis-rs translate hu-hu-g1.ctb --tracing command, I get this as a result:

root@hammera-pc:/usr/src/liblouis/tables# louis translate hu-hu-g1.ctb --tracing
> 1
⠼⠡
| From | To | Rule | Stage
---+------+----+------------+-------
1 | | ⠼ | numsign ⠼ | Main
2 | 1 | ⠡ | digit 1 ⠡ | Main

Does louis-rs use a different algorithm to determine the precedence order? I could fix the include line in the hu-chardefs.cti file to the litdigit6Dots.uti file, but the original line has been defined in the original way for a long time, if possible, I would not risk it if the problem can be handled differently in the case of louis-rs side.
Other language tables could also be affected by a similar include order?

I also tried to see what happens if I translate only the lowercase braille letter pair sz from normal text to braille, the 1-5-6 dot combination appears correctly (i.e. the ⠱ symbol, implemented with the always sz operator 156 code line).
On the other hand, if I want to translate the Sz or SZ text piece to Braille output using louis-rs, the always rule is not executed, since louis-rs exposes the appropriate indicator (capsletter or begcapsword indicator) and separately translates either the s or the s and z letters according to the base upperclass class, depending on whether I just entered a starting uppercase Sz or an all-uppercase SZ text piece. The original implementation of Liblouis executes the always rule in all cases.

[hammera]

Chris, I updated from rust-rs Github repo the release (simple doed a cargo build --release command and tested latest changes).
Since you doed a change this day with always opcode related, except numbers part related, the 1-sz, 1-Sz-1, and 1-SZ-1 examples produce right braille output the always opcode part with louis-rs project.
Look the change, I this evening updated the build from your repository:

root@hammera-pc:/louis-rs/louis-rs# target/release/louis translate hu-hu-g1.ctb --tracing
> 1-Sz
⠼⠡⠤⠨⠱
   | From | To | Rule         | Stage 
---+------+----+--------------+-------
 1 |      | ⠼  | numsign ⠼    | Main  
 2 | 1    | ⠡  | digit 1 ⠡    | Main  
 3 | -    | ⠤  | hyphen - ⠤   | Main  
 4 |      | ⠨  | capsletter ⠨ | Main  
 5 | sz   | ⠱  | always sz ⠱  | Main  
> 1-SZ-1
⠼⠡⠤⠨⠨⠱⠤⠼⠡
   | From | To | Rule           | Stage 
---+------+----+----------------+-------
 1 |      | ⠼  | numsign ⠼      | Main  
 2 | 1    | ⠡  | digit 1 ⠡      | Main  
 3 | -    | ⠤  | hyphen - ⠤     | Main  
 4 |      | ⠨⠨ | begcapsword ⠨⠨ | Main  
 5 | sz   | ⠱  | always sz ⠱    | Main  
 6 | -    | ⠤  | hyphen - ⠤     | Main  
 7 |      | ⠼  | numsign ⠼      | Main  
 8 | 1    | ⠡  | digit 1 ⠡      | Main  
> 

Partially this change is a good news, I think following commit resulted this positive change:

commit d4fa6a84e280ef9ed6a81b22cd0178860bdb9bc6
Author: Christian Egli <christian.egli@sbs.ch>
Date:   Thu Feb 12 11:13:23 2026 +0100

    Make sure always and word rules are case insensitive
    
    They were so before but didn't have precedence

So, we need solve only the digit related issue (this testcases need apply louis-rs too with litdigit, not digit the numbers related, same with Liblouis doing), and need solwing the abortuszszabályozást word example related the \7f character related issue (back-translation Liblouis correct replace the proper example the 7f simbol with ly letters).
A previous comment I showed this word the difference, but I not have ydea need solve this problem with table level, or louis-rs side (don't known the differences the two algorithms related).

Attila

[egli]

Hi Attila

Partially this change is a good news, I think following commit resulted this positive change:

I did some more changes today that should fix the problems with case insensitive rules.

So, we need solve only the digit related issue (this testcases need apply louis-rs too with litdigit, not digit the numbers related

Yes, the litdigit vs digit issue. When is liblouis using litdigit and when is it using digit?

[hammera]

If I see right, hungarian tables related Liblouis always use the litdigit rule, because this opcode the last order the precedence.
First included the hu-chardefs.cti subtable the digits6dotsplusdot6.uti, and after this, the hu-hu-g1.ctb and hu-hu-g2.ctb main tables include the litdigit related subtable file.
So, the 1-sz, 1-sz-1, 1-Sz, 1-Sz-1, 1-SZ, 1-SZ-1 type rules need use louis-rs the litdigit opcode rule (if use the precedence order).
I don't no how determine original Liblouis with what rule winning this testcase final (litdigit is the right result), but the original implementation is correct determine the opcode with forward and backward translation.

Attila

[hammera]

Chris, I founded perhaps another issue the simple sz letter back-translation related.
In liblouis, when I backtranslate the dot 156 combination (a simple sz letter combination), happen following sequence the hu-hu-g1.ctb table related:

root@hammera-pc:/louis-rs/louis-rs# lou_trace  unicode.dis,hu-hu-g1.ctb -b
⠱
sz
1.	prepunc	sz	156

When I use louis trace hu-hu-g1.ctb -d backward command, I get following result:

root@hammera-pc:/louis-rs/louis-rs# target/release/louis  trace hu-hu-g1.ctb -d backward
> ⠱
5
┌───┬──────┬────┬───────────┬───────┐
│   │ From │ To │ Rule      │ Stage │
├───┼──────┼────┼───────────┼───────┤
│ 1 │ ⠱    │ 5  │ digit 5 ⠱ │ Main  │
└───┴──────┴────┴───────────┴───────┘
> 

In Liblouis, the prepunc sz 156 rule are defined with the tables/hu-hu-g1_braille_input.cti file.
Same error happen the ⠩ rule related when I doing a back-translation, louis-rs not execute the postpunc opcode, simple back-translate now the ⠩ braille input with digit opcode.
Right output from Liblouis latest development release:

root@hammera-pc:/usr/src/liblouis/tables# lou_trace unicode.dis,hu-hu-g1.ctb -b
⠩
cs
1.	postpunc	cs	146

Wrong output in louis-rs command (I used the latest development version):

root@hammera-pc:/usr/src/liblouis/tables# /louis-rs/louis-rs/target/release/louis  trace hu-hu-g1.ctb -d backward
> ⠩
3
┌───┬──────┬────┬───────────┬───────┐
│   │ From │ To │ Rule      │ Stage │
├───┼──────┼────┼───────────┼───────┤
│ 1 │ ⠩    │ 3  │ digit 3 ⠩ │ Main  │
└───┴──────┴────┴───────────┴───────┘
> ^C

Have any limitations now in louis-rs the prepunc and postpunc rules length related with difference the original Liblouis comparison related?

Attila

[egli]

Hi Attila

Thanks for testing. You list a number of problems

1. Numbers translated with digit instead of litdigit. I do not understand the difference between those two opcodes. When should I use the definition from digit and when litdigit?
2. Allcaps words. This has not been implemented
3. Backtranslation. Sort of works, but indication is not taken care of at all at the moment

[egli]

Regarding the backwards translation and prepunc. I think the functions that search for boundaries in the input only work for forward translation at the moment. I added a note to `TODO

[hammera]

Hi Chris,

I see your letter with litdigit and digit opcode related question in Liblouis list.
Very good the question, because, for example in hungarian language grade1 and grade2 level always need handle technically with six dot braille with litdigit opcode, both forward and backward translation, because before in first digits, always need putting the numsign indicator. The situation is different in 8 dot computer Braille the hungarian Braille rules, computer braille not need use the numsign indicator, similar perhaps with other languages (english for example not use too computer Braille mode the numsign indicator).
But, technically what the difference the original Liblouis aimplementation the digit and litdigit opcode algorithm?

The context, and other multipass forward and backward translation if need, I always use the $D attribute (literary digit attribute) the required rules.
So, perhaps louis-rs not handle simple right the include order with subtable files (this is a tip only), first I included the tables/hu-chardefs.cti file the digit6dotsPlusDot6.cti file, and after this, final the litdigit related file are included with main hu-hu-g1.ctb file and hu-hu-g2.ctb file.
Not possible the last include file are the winner in original Liblouis this situation, and this difference resulting to this testcases are works perfect in Liblouis?
So, it could be that the banal difference between the original and the current louis-rs implementation is that in the original Liblouis implementation, if the digits6dotsPlusdot6 file is included in a subtable file first, and the file starting with litdigit6dots is included in the main table later, the last file wins in the precedence order.
I can't find any other explanation for the phenomenon, theoretically this difference can only be at the table implementation include order handling level. I hope you're making the right conclusion. So, because I am not known Louis-rs how can handle the include order this situation, this is a theoratically tip only. :-):-)
So, if I understood Bue's explanation correctly, he's basically right, e.g. from the point of view of the Hungarian language as well.
Bue writes in Liblouis list your digit and litdigit opcode question related thread:

Hi Christian,

I can't answer the last question, but I would look for the use of litdigit in the context of numsign and the various associated rules (begnum, midnum endnum etc.). Perhaps litdigit, strictly speaking, shouldn't be a character definition, as it is more a definition of the Braille cells to use when specifying digits in the context of numsign etc.

The digit opcode defines digits when numsign is not used, e.g. in the case of compbrl, or if numsign is not defined, which it usually isn't in computer braille tables.

HTH a bit
Bue

Thank you other answers and todo entries.

Attila