Open bertfrees opened 9 years ago
Does the dash prefix in -louis-undefined
work already?
I'm a bit hesitant to use a temporary table file to compile the undefined
rule. Programmatically compiling this rule is a bit cleaner, but as discussed on IRC it may not work correctly in liblouis 2.6.4.
Another question is if we need this generality. NLB already implemented this in their module (pipeline-mod-nlb#6) and Celia/Dedicon could do the same. I think it boils down to the question if there will be a future use for compiling programmatically (or through a temporary table file). If not, let's do it in the agency modules for now. If there is a need, let's fix liblouis. :)
OK, fine by me. I'm not against keeping things simple. I thought this could be a good way to enable/disable the alert feature (https://github.com/snaekobbi/pipeline-mod-braille/issues/54).
Let's keep it in mind for later then.
The dash prefix is just an arbitrary thing, nothing special happens with it. It's not automatically filtered out for non-Liblouis translators or something like that, if that's your question. But it is supported by the CSS parser.
I meant to ask if the parser supports it.
Are you suggesting that alerting the user of unknown characters should be enabled automatically if the CSS property -louis-undefined
is used? That works, but IMO the alerting should be a configuration option (as should be the logging level in general).
No I meant if -louis-undefined:abort
is used. But maybe you are right that it should be a general configuration option. And maybe you want to use a fallback character AND alert the user.
As a start, the liblouis based translator could support a property called
-louis-undefined
which would map to a liblouis "undefined" rule. A table file with a single "undefined" rule would be generated on the fly. The value of-louis-undefined
should be a<braille-character>
. Possibly we can allow additional values such asabort
.Related issues: