eBraille MVP

[wfree-aph]

• Navigation
  • Links- could be either to a location inside the current document or to a location within another document within the eBraille bundle or to an URL
  • The ability to navigate to structural elements
  • Should leave open the possibility to synchronize navigation between several versions of the text (e.g. contracted braille and ink print version of the text)
• Semantic markup- necessary so the file can be reflowable for different displays sizes or, for embossing, paper sizes. Also useful for navigation.
  • Headings
  • Paragraphs
  • Lists
  • Tables
  • Page numbers
  • Preformatted content
  • This is material that may not be accurately reflowed and so will need to be navigated both vertically and horizontally or could preclude the text being displayed or embossed using that particular hardware
  • Preformatted content will appear alongside reflowable content and is not segregated in its own file
  • It would be best if we could avoid preformatted content entirely because of the exception it represents to our goal of having an entirely reflowable document but this requirement is in the MVP because it is a compromise we may need to make
  • Braille code changes
  • Identified primarily for backtranslation and potentially for reading system-level Text-to-Speech support.
  • The need to switch braille codes within a single file varies throughout braille regions. In the US, it is common to switch braille codes. The most common example is when switching from UEB for literary material to Nemeth for technical material.
  • Braille grade changes
  • Identified for the same reason as braille code changes.
  • Like switching braille codes, the need for this varies throughout the world but it is common in the US and Canada. In those countries, an example of switching between braille codes would be in a glossary entry that has an example of how the word is pronounced. In examples like this one, the glossary entry is shown contracted, then uncontracted, and then followed by the pronunciation example.
  • Typeforms and emphasis (as they are expressed in braille)
• Formatting
  • CSS telling the reading software how to display the content according to the local rules of braille.
• Tactile Graphics
  • Support for at least two appropriate tactile graphic file formats
  • Support for alt text and extended descriptions
• Metadata
  • Braille code(s)
  • Identifies any braille codes used in the file.
  • Braille grade(s)
  • Identifies any braille grades used in the file.
  • Recommended braille layout
  • Line per page and cells per line
  • Line spacing (single, double, triple, etc.)
  • This item reflects the recommendation of the braille producer and does not limit the file to the layout specified
  • Tactile graphic file type(s)
  • Support for different tactile graphic file types could vary among different hardware
  • Language(s)
  • Minimum page size
  • This will allow the reading system to know if it's even possible to display or emboss the file using the current hardware
  • Would be determined by any sections that are preformatted and the necessary display size and file type of tactile graphics.
  • Would be on the reading system to interpret this information and know the limitations of the hardware
  • Source document information
  • Title (required)
  • Author (required)
  • ISBN (where applicable)
  • Publisher (where applicable)
• Encoding
  • Unicode, UTF-8
• Implemented at launch
  • 2 authoring tools- these will be software that can be used to make valid eBraille files
  • 1 validator- this tool will ensure that an eBraille file meets the standards of the specification
  • 2 reading solutions- these will be tools that can be used to read eBraille files

[avneeshsingh]

Regarding bullet points on:

• Braille code changes.
• Braille grade changes.

More explanation would help. Are we saying that the EBraille document can contain characters in different Braille codes and we need to have a mechanism for marking the braille code of different chunks of the text?

[wfree-aph]

Yes, that's what I was thinking. In the US, for example, it is common to switch braille codes and while we have indicators that make that clear within the braille, it would be useful to identify these using markup. The most common switch is from UEB literary to Nemeth for technical materials.

On braille grade changes, that is also common. A good example here is when you have a word in a glossary that is followed by a pronunciation key, that word will be showed contracted, then uncontracted, and then have the pronunciation key. This is done, I think, to ensure the student's pronunciation of the word is not affected by the use of contractions.

I will add these examples to the document.

[andrewflatres1]

I think these two will extremely difficult to include when we look at it from a language perspective. Unlike Latin and non-Latin print where you could have a detection, from a braille first, unless there is a particular sign that is recognised as a change of braille code and language, I don't see how this is possible. Correct me if I am wrong, but there is no such identifier that says to a user this is a foreign language / different braille code. If this is the case, perhaps it will need to be requested in a new UEB revision.

Thanks Andrew

From: Avneesh Singh @.> Sent: 13 December 2022 12:09 To: daisy/ebraille @.> Cc: Subscribed @.***> Subject: Re: [daisy/ebraille] eBraille MVP (Issue #41)

EXTERNAL EMAIL - Be vigilant with attachments and clickable links. COURRIEL EXTERNE - Attention aux pièces jointes et aux liens cliquables.

Regarding bullet points on:

• Braille code changes.
• Braille grade changes.

More explanation would help. Are we saying that the EBraille document can contain characters in different Braille codes and we need to have a mechanism for marking the braille code of different chunks of the text?

- Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdaisy%2Febraille%2Fissues%2F41%23issuecomment-1348392371&data=05%7C01%7C%7C929ed658d3564f587f2a08dadd02c366%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065301195706503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=txfmLMQ3arVzzHaeYLonUIP5v%2BaWlAUy8AQ7xsM2HI0%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA3F2L23YQPHW4DPR3JZ3YEDWNBRMHANCNFSM6AAAAAAS334QFA&data=05%7C01%7C%7C929ed658d3564f587f2a08dadd02c366%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065301195706503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yQnMaz5znYT94zCVg07h0lHvRZasnYfTp3QsICQSIFw%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[wfree-aph]

Hi Andrew, I'm thinking that braille code changes will be identified at the time of document creation. Braille transcription programs can know that the braille code has changed. An exception to this would be when the user has used six-key entry to switch braille codes but there could still be a mechanism for the transcriber to identify that they have done this kind of manual switch.

Braille grades are even easier since transcribers are more likely to use the tools available within the transcription program to identify material as needing to be contracted or uncontracted and letting the translation happen automatically.

[andrewflatres1]

Hi William,

Sure, from the creation part, it could be done, but I am still unsure how the user will be able to detect the language change if both languages use six dot entries. There is also the case of the various Language methods that can be used, Method 1,2 and 3 for foreign languages. Performing backward translation could get messy if the user has to choose from a list of braille tables to convert to. Here I am thinking of education more so.

There would have to be a braille indicator that informs the user of a change of language and code. The same method could be used so the refreshable braille device can switch the TTS, giving the option to the braille manufacturer to implement such a need.

So to summarise, there would need to be a new braille rule/symbol to tell the user that the next braille signs are of a different braille table. Similar to how UEB has a grade 1 indicator, although this is limited to a set of characters after the indicator. You could go further to give what code exactly or keep it simple to notify a user of a change. It would be the same example as a print reader who sees Latin text, then mandarin or Arabic. You wouldn't necessarily know what language it is, but you at least know it's a different language.

Thanks Andrew

From: wfreeman-aph @.> Sent: 13 December 2022 12:38 To: daisy/ebraille @.> Cc: Andrew Flatres @.>; Comment @.> Subject: Re: [daisy/ebraille] eBraille MVP (Issue #41)

EXTERNAL EMAIL - Be vigilant with attachments and clickable links. COURRIEL EXTERNE - Attention aux pièces jointes et aux liens cliquables.

Hi Andrew, I'm thinking that braille code changes will be identified at the time of document creation. Braille transcription programs can know that the braille code has changed. An exception to this would be when the user has used six-key entry to switch braille codes but there could still be a mechanism for the transcriber to identify that they have done this kind of manual switch.

Braille grades are even easier since transcribers are more likely to use the tools available within the transcription program to identify material as needing to be contracted or uncontracted and letting the translation happen automatically.

- Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdaisy%2Febraille%2Fissues%2F41%23issuecomment-1348465363&data=05%7C01%7C%7C16212e2960f04971435508dadd06e401%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065318920476125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aQb1OvDysh12cK8cYIwg1W8sjwAzupWFY5comE%2Fg0gc%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA3F2L27VNEJOIW6IHX6YNITWNBU3BANCNFSM6AAAAAAS334QFA&data=05%7C01%7C%7C16212e2960f04971435508dadd06e401%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065318920476125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PDAnzaf5Qvze%2BuAGoi7UTGX1gQpEXtI%2B4I7ZnGlVNpc%3D&reserved=0. You are receiving this because you commented.Message ID: @.**@.>>

[ManfredMuchenberger]

Hi William In order to not prevent future use of our ebraille, I would put an extra item under "Navigation" even if we didn't put the use case #7 as highest priority. Something like "The ability to navigate between several versions of the text in a synchronized way (e.g. contracted Braille and ink print version of the text)." Thanks Manfred

[GeorgeKerscher]

I think that having navigation to multiple versions is a great idea. There is this notion of parallel versions that allow a switch to a different version without loosing your place. It is also possible to have an audio parallel version where you could have human narration recorded and synchronized with the braille. This could open many doors.

[wfree-aph]

Thanks @ManfredMuchenberger and @GeorgeKerscher, I've added a third bullet point under Navigation that reads "Should leave open the possibility to synchronize navigation between several versions of the text (e.g. contracted braille and ink print version of the text)"

[wfree-aph]

@andrewflatres1, I'm really thinking that the markup will be added when the document is created. Duxbury already has tools that the transcriber can use to change languages, if they use those tools, the transcriber would never even need to know that the eBraille file needs this information and it would just be added automatically. There's similar tools for braille grade changes in BrailleBlaster and Duxbury. Duxbury also has a similar feature, I think, for braille code changes. With these tools, everything we need is basically automatic and the transcriber is doing the least work for the most benefit for themselves and the reader.

[mattgarrish]

I think that having navigation to multiple versions is a great idea.

Yes, but a "minimally viable product" is meant to set the bare baseline of features. The things you "must" have, in normative speak. It's the base you start building up from so you aren't trying to develop everything all at once. In general terms, the minimum in order to be able to make a very simple prototype.

If it turns out the MVP completely disallows a less critical feature wanted by the use cases, then you can return to figure out what needs changing, but I wouldn't start by trying to account for features that aren't considered critical.

[mattgarrish]

Given that #11 is considered high priority, you're probably going to want to add a means of identifying and ordering the resources to the MVP.

I don't see providing a container for the pieces mentioned in the use case, but it's another consideration when you break documents down into smaller pieces. I don't think it needs to be taken up in the initial minimal definition, though, beyond maybe a note that compression will be defined later. (You need something to zip first.)

[avneeshsingh]

"minimally viable product is meant to set the bare baseline of features.”

+1 to Matt.

To simplify it further from our group’s perspective. Looking at a timeline of 1 to 1.5 years, what are the minimum set of features that we would like to have in the first iteration.

[ManfredMuchenberger]

I think that having navigation to multiple versions is a great idea.

Yes, but a "minimally viable product" is meant to set the bare baseline of features. The things you "must" have, in normative speak. It's the base you start building up from so you aren't trying to develop everything all at once. In general terms, the minimum in order to be able to make a very simple prototype.

If it turns out the MVP completely disallows a less critical feature wanted by the use cases, then you can return to figure out what needs changing, but I wouldn't start by trying to account for features that aren't considered critical.

I see, that implementing ebraille that can also be read by TTS is not high priority by most. But for some of us this is high priority for the future. I don't want to make it a requirement, that there has to be an ink print text version in eBraille. But if we don't put a mechanism in the specification to "synchronize navigation between several versions of the text" I think, that we will never be able to put it in place in a later stage. In my opinion, app providers need to put such a fundamental function in place from the beginning. Otherwise we would end up in another chicken-egg-situation. This is also one of the reasons that multiple renditions did never pick-up in EPUB. We wanted to produce EPUBs with a Unicode Braille rendition in parallel to the ink print text for years but there is no app that is able to play it.

[andrewflatres1]

Hi William Yes, I was aware that Duxbury has this, but if you are just reading braille on the refreshable device, how will they know of a change in the braille code? The alternative option is to have the manufacturer device set some notifications, but this would not be standard. I think a better approach would be to include a UEB standard symbol dedicated to indicating a change in the language to the user. This way, anyone reading physical or refreshable braille paper could easily identify the language change.

I don't know what benefit it would bring to have the ability to create the tags if the output is not easily identifiable. Perhaps the only advantage is when translating braille to print, but this would be a challenge

Thanks Andrew

From: wfreeman-aph @.> Sent: 13 December 2022 19:24 To: daisy/ebraille @.> Cc: Andrew Flatres @.>; Mention @.> Subject: Re: [daisy/ebraille] eBraille MVP (Issue #41)

EXTERNAL EMAIL - Be vigilant with attachments and clickable links. COURRIEL EXTERNE - Attention aux pièces jointes et aux liens cliquables.

@andrewflatres1https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fandrewflatres1&data=05%7C01%7C%7Cc1096876f4ec4e1bd3fa08dadd3f9a72%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065562517716243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qmOwvdrftgEjN4Yc%2F9GYDDm%2BwGUD1EqaZ2ndDcf8itc%3D&reserved=0, I'm really thinking that the markup will be added when the document is created. Duxbury already has tools that the transcriber can use to change languages, if they use those tools, the transcriber would never even need to know that the eBraille file needs this information and it would just be added automatically. There's similar tools for braille grade changes in BrailleBlaster and Duxbury. Duxbury also has a similar feature, I think, for braille code changes. With these tools, everything we need is basically automatic and the transcriber is doing the least work for the most benefit for themselves and the reader.

- Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdaisy%2Febraille%2Fissues%2F41%23issuecomment-1349572349&data=05%7C01%7C%7Cc1096876f4ec4e1bd3fa08dadd3f9a72%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065562517716243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JJS2X1VNjuzcbbNRRt36%2FYVhmMx%2BhIXa%2BpnoEUohs%2Fo%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA3F2L23Q3MQYGGAOZXIH563WNDENNANCNFSM6AAAAAAS334QFA&data=05%7C01%7C%7Cc1096876f4ec4e1bd3fa08dadd3f9a72%7Ca20dee1502224c59b520fa220fd6eb14%7C0%7C0%7C638065562517716243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XSAQjt2SQl9wjfsu%2BAF47OGQk1VzuvuIFxcPrpX5nso%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.**@.>>

[mattgarrish]

I think, that we will never be able to put it in place in a later stage.

Again, I think there's a misunderstanding of minimal viable product. You can't design hooks for something that you haven't developed yet. We need to know what a basic ebraille file is going to look like before there's any hope of figuring out what bundling and linking between multiples of them would look like.

This is also one of the reasons that multiple renditions did never pick-up in EPUB.

Multiple renditions didn't fail in epub for authoring reasons. It was very simple to retrofit a few attributes in the container.xml file to differentiate the purpose of the renditions. Even the mapping file wasn't technically problematic to add.

Multiple renditions has gone unused because mainstream publishers have shown no interest in bundling multiple versions of a publication. It was a solution without a problem. Publishers have repeatedly said they distribute single publications targeted to their audience (i.e., they don't put two language versions together, or fixed layouts with reflowable content).

It's also been ignored by reading systems because it's very complex to implement, and when publishers aren't going to create content that way in any significant amounts developers aren't going to put the time in. It's not that getting the information about the available renditions is hard, but what you then have to do with that information that is (what to show in a bookshelf so the user knows there are multiple versions, what metadata to display, how to open the rendition you want, when to allow switching, what interface to provide users, where this interface lives in the UI, etc.).

There may be a more focused case here that doesn't require multiple languages, multiple layouts, etc., but you're still going to face the same daunting problem of making switching between renditions work. The hooks are easy in comparison.

[wfree-aph]

@andrewflatres1 Thanks for this clarification. I am not thinking that language, code, and grade tags are information that necessarily needs to be conveyed to the user via braille. Instead it would be options for the reading system when backtranslating or could be delivered to the user via options found on that reading system. We don't need to handle how these tags are implemented by the reading system (though I agree it is useful to discuss that aspect of it). The reading system may have audio options that explain that information to the user or add optional braille symbols via a setting or something. A really advanced reading system might offer translation options. My point in including them is to make these features possible. Based on Matt Garrish's points, we may not need these tags in the MVP (except for language since it is free).

[ManfredMuchenberger]

I think, that we will never be able to put it in place in a later stage.

Again, I think there's a misunderstanding of minimal viable product. You can't design hooks for something that you haven't developed yet. We need to know what a basic ebraille file is going to look like before there's any hope of figuring out what bundling and linking between multiples of them would look like.

This is also one of the reasons that multiple renditions did never pick-up in EPUB.

Multiple renditions didn't fail in epub for authoring reasons. It was very simple to retrofit a few attributes in the container.xml file to differentiate the purpose of the renditions. Even the mapping file wasn't technically problematic to add.

Multiple renditions has gone unused because mainstream publishers have shown no interest in bundling multiple versions of a publication. It was a solution without a problem. Publishers have repeatedly said they distribute single publications targeted to their audience (i.e., they don't put two language versions together, or fixed layouts with reflowable content).

It's also been ignored by reading systems because it's very complex to implement, and when publishers aren't going to create content that way in any significant amounts developers aren't going to put the time in. It's not that getting the information about the available renditions is hard, but what you then have to do with that information that is (what to show in a bookshelf so the user knows there are multiple versions, what metadata to display, how to open the rendition you want, when to allow switching, what interface to provide users, where this interface lives in the UI, etc.).

There may be a more focused case here that doesn't require multiple languages, multiple layouts, etc., but you're still going to face the same daunting problem of making switching between renditions work. The hooks are easy in comparison.

Thank you for explaining why multiple renditions in EPUB never picked up for mainstream publishers. This sounds quite logical. On the other hand I know, that we (and other DAISY members) up to now never produced EPUB with an additional Braille rendition, because there is no app to play it. We did have quite clear plans to introduce a Braille rendition in our EPUBs and even produced some prototype books with a basic script in DAISY pipeline. But we never wanted to develop our own app. So we started to negotiate with Dolphin to add multiple rendition in EasyReader. This is still on our roadmap but kind of on hold for now.

To my understanding, the new eBraille format will probably not be produced by mainstream publishers but by some companies like SBS. This due to the fact, that there is no money to be made by producing a book in a braille format. Maybe it could be a use case for us to enrich mainstream e-books with an additional Braille rendition to make it more accessible.

Thank you also for clarifying the concept of MVP. You of cause have much more experience with such processes. If we can add something similar like multiple rendition at a later stage that’s ok for me. If not, I think that the priority of this use case should be changed to high.

My concern is, that we (and some other DAISY members) for various reasons will probably not implement and distribute this new eBraille format as long as we can’t bundle it with an ink print text rendition.

[wfree-aph]

Added the following to the MVP:

• Implemented at launch
  • 2 authoring tools- these will be software that can be used to make valid eBraille files
  • 1 validator- this tool will ensure that an eBraille file meets the standards of the specification
  • 2 reading solutions- these will be tools that can be used to read eBraille files

[avneeshsingh]

Looking at MVP thread, it would be good to settle on three things. What is final decision on switching of braille codes in MVP? We may have to add an attribute for it, or use inline metadata.

The following can be written under heading of success criteria

• 2 authoring tools- these will be software that can be used to make valid eBraille files
• 1 validator- this tool will ensure that an eBraille file meets the standards of the specification
• 2 reading solutions- these will be tools that can be used to read eBraille files

There are some feature requests which are important but it is difficult to fit them in MVP. I think that these should be placed under a new heading of "Additional Design Considerations". I did the same in technical analysis document. i.e. Additional design considerations:

• Support multiple versions of the same content inside the publication. For example, one set of files can be of contracted braille and another version of the same content in uncontracted braille, or one set of files can be in braille and other version of files of the same content in print text.
• Ability to switch from one version to another version of the content file without losing the reading position.
• Ability to read reflowable braille as well as emboss the braille from the same braille publication. It is worth mentioning that in the principles which we established for this project, we prioritized supporting reflowable braille in case we end up with competing priorities.

[ManfredMuchenberger]

I like Avneeshe's suggestion. Putting some important mechanisms in "Additional Design Considerations" so that we don't prevent ourselves from developing further after the MVP is reached.

[wfree-aph]

Moved to wiki and added Avneesh's additional design considerations. We can make changes there if needed but am resolving this ticket for now.