Use the same file set for embossing and dynamic content

[wfree-aph]

As a braille user, I would like to use the same file set whether I am embossing the materials or using it with a dynamic braille display.

Detail: The requirements of embossed braille could be more complex than what is needed for dynamic braille. We will need to carefully consider what kind of markup is required for embossed braille.

Proposal: One solution to this problem could be that we bundle a dynamic file and a file for embossing together. Additionally, the dynamic file could link to a more traditional BRF file that aligns more closely with what is expected for embossed braille.

[ManfredMuchenberger]

As a library for the blind, we have a completely different printing environment than someone at home. I don't think that we can cover the requirements of our printing environment with this standard. This is also not necessary because we can easily transform files automatically so that they fit our printing environment.

I understand if an individual user wants to print out a short text at home. But I don't think it happens often that someone wants to print out an entire book at home.

I would therefore set the priority of this use case to low.

[Steve-Noble]

I would add that this use case is a very important one as we look to the future of the technology landscape. Many schools and agencies have invested funds into the purchase of print braille embossers, and these devices have a long lifespan. Thus, we can expect to see current embossing devices being used for several years to come. But the future of braille will likely be tied to dynamic digital tablets, which can make good use of all the extra value found in the evolving eBRF standard. So, the pragmatic approach of having the same file package support both models of braille usage makes perfect sense.

[mrhunsaker]

@ManfredMuchenberger I am a TVI and I unfortunately find myself embossing chapters, books, etc. for students. Almost weekly whenever our state braille provider gets behind. So I see this as a very critical aspect of ebraille. I need to be able to use it from the level of transcriber, as well as end user assuming someone cannot afford a braille device and needs an embossed copy, or even just a graphic.

[mrhunsaker]

I think as a coda to this issue is that any file we include for tactile graphics needs to be in a non-proprietary file format. If I have an Index embosser and use TactileView, FIrebird, or QuickTac to make graphics, I do not have a way to print out PRN files from the Tiger Software Suite (and vice versa if something is saved native to TactileView). I have been troubleshooting braille state testing in Utah and we run into problems every year with graphics files that cannot be opened for one reason or another, and using an svg or some other file could ameliorate this issue (assuming a multi-line display). Regardless, files meant for certain embossers or technologies needs to be de-emphasized in projects such as this so we do not cause any more problems than we solve.