Return error when encountering undefined input character

[dkager]

This is useful to spot characters that will not be printed correctly so they can be added to a special symbols list (snaekobbi/requirements#38). The behavior should be optional.

Some possibilities for implementation:

• Yet another parameter to lou_translate.
• Set this at compile-time.
• Add a function to check the given input for undefined characters.
• Have mod-braille check liblouis' output for undefined characters (\xHHHH or a special undefined character).

[bertfrees]

Thanks Davy. I was thinking about the last option.

[dkager]

I was thinking about the last option.

Makes sense. Some questions:

• Can we come up with a dot pattern that can be guaranteed not to show up in the actual output?
• Does liblouis allow to compile the undefined opcode on-the-fly even if a table already defines it? I think the NVDA devs ran into this problem.

[bertfrees]

No need for a special (real) dot pattern. We just need to set undefined to a virtual dot pattern that is unlikely to be used in a table, and map it to some unicode character that is very unlikely to be used.

If you set undefined before loading another table that already defines it, the first definition should be picked. I haven't tried it but that should work.

[egli]

From a liblouis perspective I think it would be beneficial if liblouis itself would be able to provide warnings for "faulty" tables without the need for another tool such as mod-braille, so I'm not too keen on the last option.

Another thing to consider is that liblouis is used as a library and needs to have a way to gracefully handle missing definitions.

Maybe a separate function that returns a list of chars that have no definition would be the best option.

[dkager]

@bertfrees Awesome. I can have a look at this if you consider the priority high enough. I'm not sure if this relates to a specific requirement but if you want to assign it to a future sprint I'll give it a shot then.

@egli Of course the list of undefined characters depends on the input. But liblouis could log a warning for these (maybe it already does, I haven't checked). If that log is piped into the mod-braille log a user could simply use that. But maybe the liblouis log is too spammy by default?

[bertfrees]

I don't think the liblouis log is too spammy, not if you set the level to WARNING.

[dkager]

So if we ensure this gets logged that would be enough? This would not abort the conversion process but the question is if that is desirable anyway. And we could always check for that in mod-braille as described above.

[bertfrees]

The separate function won't work. Maybe a new bit for the mode parameter could work, although I'm not sure the mode parameter was designed for these things.

Anyway, let's start with supporting this at least in mod-braille, shouldn't be too hard.

[dkager]

When do you want to do this? I’m not too familiar with mod-braille yet but I think this shouldn’t take long to implement.

[dkager]

Revisiting my list of possible implementations:

• Yet another parameter to lou_translate.

This is my preferred choice. Or use the mode flag as @bertfrees suggested.

• Set this at compile-time.

Neh.

• Add a function to check the given input for undefined characters.

Because of context rules this basically means performing a translation and seeing if it ran into undefined characters. Not very efficient. An algorithm could be defined for this, but that's probably more work than it's worth.

• Have mod-braille check liblouis' output for undefined characters (\xHHHH or a special undefined character).

The problem with this is that you would have to pick a virtual dot pattern and Unicode character that is not likely to be used in a table and input file. I don't think "not likely" is good enough. It also doesn't solve the problem for other parties interested in the same functionality. But if we choose this we should do snaekobbi/pipeline-mod-braille#57 first.