Test braille-utils support for Braillo 650SF

[dkager]

Ref.: brailleapps/brailleutils@db53c51

[bertfrees]

See also: brailleapps/brailleutils#66

[dkager]

We should do this as soon as braille-utils is ready for it.

[joeha480]

It's been ready for test for quite some time. I am waiting for the test result.

[dkager]

Two issues:

1. Capital letters are transformed into lowercase letters. This is OK, they lead to the same dots, but I thought I had addressed this in braille-utils.
2. Numbers are rendered as a-j, not 1-0. This is a misunderstanding on my end of the correct output. Again, the dots it produces are identical, but I should probably check into this.

[dkager]

Ah, are supplements not used in the conversion from Unicode braille to ASCII? @joeha480

[joeha480]

@dkager No, it appears that it's only text to braille and not the other way around. The main purpose is to produce braille on paper. The ASCII file is really only produced as a way to communicate with an embosser and for that purpose (like you say) you only need one translation. I know I've made some minor exceptions to this rule here and there, but there isn't any support for reverse translation, i.e. determining if a braille pattern is e.g. a, 1 or A. Quite a bit of work would probably be needed to support such use cases properly. If we're can limit ourselves to reversible one-to-one translations, I would be interested in creating a general description syntax for this.

See also brailleapps/brailleutils#70

[dkager]

Makes sense. Our current conversion goes from input text to ASCII without converting to Unicode braille. It can therefore decide whether it should insert a letter or a digit. The transcribers check the BRF output, but this change should be fine for them. If not the PEF is very clear.

I haven't spotted any errors in the books I converted. We haven't done any prints yet, but if the bRF is right the print should come out right.

[bertfrees]

Could PEF be extended to do things similar to what "Extended braille" can do?

Extended braille, in contrast to ASCII Braille and other standard digital representations of braille, uses separate character codes for each different meaning of the braille cells rather than for each different cell. Extended braille for (English) Grade 2 braille has approximately 500 character codes rather than only 63.

I know this contrasts somewhat with the PEF idea of representing braille unambiguously, because the "meaning" of the "extended" characters are locale dependent. But maybe you can find a way to work around that, maybe by using generic "classes" such as "capital" and "number".

[bertfrees]

Apart from the issues with reverse translation, is there anything else holding us from releasing the 650SF table?

[joeha480]

@bertfrees Well, I was hoping @dkager would try to emboss on some of the embosser models Alan added, e.g. Braillo 650SF

[dkager]

Yes, generic classes sound universally applicable, which is their whole point of course. But I’m not sure if this is valuable enough to look into. E.g. is #1 really more readable to #a (if you know that a-j are used to indicate numbers). I’ll have to check with the transcribers on this.

[dkager]

I took the table from our current in-house conversion, so if we assume that that is correct, then the table is too. Does the driver have any other features I need to test?
I’ll try to get a ‘real’ test to the embosser soon.

[dkager]

@joeha480 The plan is to emboss a BRF file. Is there anything to watch for besides correct output characters?

[dkager]

TBD this week.

[bertfrees]

Not sure whether this was done. Moving back to backlog for now...

[dkager]

It was done briefly but needs further attention in 2017.