Braille should also be allowed to be ASCII braille, and notably many-to-one mappings (multiple characters to represent the same braille cell) should be supported.
The two main purposes of this are:
To be able to use ASCII braille in PEFs to make the unit tests easier to read.
To be able to make PEF previews that has different representations of the same braille cell in different contexts. For example a ⠁ (dot 1) can be represented by A or 1. This makes braille files easier to read by sighted people.
Several things need to be done:
[ ] In braille CSS we need a definition of "braille" that does not impose an encoding. I elaborated a bit on this in nlbdev/pipeline#153.
[ ] The BrailleTranslator interface should get a getBrailleCharset() method that returns a Table to indicate which character set is used in the output.
[ ] Ideally it should be possible to select a braille translator based on a certain Liblouis translation table and Liblouis display table. It is already possible to select a translation table and to use that translation also as display table, by including (output:ascii) in the query. However this not so great because not every translation table is designed to be also a display table (with a well-defined behavior).
[ ] PEF needs to be extended to allow other characters than the ones in the 2800-28FF Unicode range. The used character set (Table.getIdentifier()) should be set in the PEF metadata. It's probably also a good idea to also give the PEF a custom version attribute. This will most likely stay a unofficial Pipeline specific extension. In practice it means writing a custom Dotify "media writer".
[ ] css-to-obfl might need some minor changes.
[ ] obfl-to-pef will need some changes. Firstly it needs to be adapted to the above-mentioned changes to the BrailleTranslator API. Also a solution needs to be found for NumberBrailleTranslator. Then it should interpret the mode and locale options as a BrailleTranslator and use it to insert the right metadata into the output PEF.
[ ] px:pef-store should look at the PEF metadata to convert the custom PEF to a true one (with Unicode braille), and to create a PEF preview file from it (no need to do a re-coding when the charset of the PEF matches the charset specified with preview-table).
bertfrees
commented
2 years ago
Braille should also be allowed to be ASCII braille, and notably many-to-one mappings (multiple characters to represent the same braille cell) should be supported.
The two main purposes of this are:
⠁(dot 1) can be represented byAor1. This makes braille files easier to read by sighted people.Several things need to be done:
BrailleTranslatorinterface should get agetBrailleCharset()method that returns aTableto indicate which character set is used in the output.(output:ascii)in the query. However this not so great because not every translation table is designed to be also a display table (with a well-defined behavior).Table.getIdentifier()) should be set in the PEF metadata. It's probably also a good idea to also give the PEF a custom version attribute. This will most likely stay a unofficial Pipeline specific extension. In practice it means writing a custom Dotify "media writer".css-to-obflmight need some minor changes.obfl-to-pefwill need some changes. Firstly it needs to be adapted to the above-mentioned changes to theBrailleTranslatorAPI. Also a solution needs to be found forNumberBrailleTranslator. Then it should interpret themodeandlocaleoptions as aBrailleTranslatorand use it to insert the right metadata into the output PEF.px:pef-storeshould look at the PEF metadata to convert the custom PEF to a true one (with Unicode braille), and to create a PEF preview file from it (no need to do a re-coding when the charset of the PEF matches the charset specified withpreview-table).