How to apply tags to single emphasised character in contraction

[mwhapples]

When creating an ebrf, if I have a word where the first letter is emphasised but the word starts with a contraction, then how should I apply the emphasis XML tags. This is probably best demonstrated with an example. If I have the word "this" where the "t" is in bold, the Braille in UEB would be ⠘⠆⠹. Looking at the eBraille examples normally one would place the bold Braille, including the bold indicator, inside a strong XML element. For cases like the example in this issue it is not possible to place only the letter which is bold inside a strong element due to the contraction representing multiple latin letters. To wrap the entire contraction will capture more letters than should be inside the strong element and may give issues when reading the EBRF. To only include the emphasis indicators in the strong element would then be missing letters which are actually emphasised. Neither option seems to be an accurate representation of the content and so is why I am asking for clarity on how this situation should be handled. Whilst the example I have given is a single cell contraction, multi-cell contractions could equally give similar problems, for example "word" where the "w" is bold. I think in theory a similar problem exists where the contraction is not a word and where the contraction is either in the middle of a word or at the end of a word and the emphasised character is the first character of the contraction. I say in theory here because I guess the real world cases of these would be much less than the first letter of a word cases.

[jrbowden]

Good catch, and we have to wonder why we want to actually mark bold and italic in the mark-up: it has no bearing on braille presentation, unless we capture the indicators themselves in order to hide them. Reasons for marking bold etc then come down to a possible navigation command (which would take you to the first affected character) or reverse translation. There are other cases where braille shows something that doesn't exist in print, such as a transcriber note indicator, dot locator etc. So perhaps we need to split "braille rendering" from "original text" - this gets messy and, if taken to extreme, you get both the original and braille text in parallel streams. e.g. ⠘⠆⠹this

Looks messy and I'm sure there's a better solution. Just a starter for ten.

[mwhapples]

Here are some thoughts I have on the topic.

• Using standard HTML/XHTML tags does mean that the XML of an EBRF can be viewed in a browser and certain structural information can be observed, including with a screen reader. Whilst its been a nice trick to pull when developing software to create an EBRF, viewing the EBRF XML in a browser probably isn't really what we expect people to do so it probably shouldn't drive the decisions.
• May be rather than surround the Braille the indicator applies to, may be it should be elements for the Braille indicators. So for the bold letter indicator it may be a span containing ⠘⠆ and a class attribute to specify its a Braille bold letter indicator. Why even mark up the indicators? It may help with back translation and/or navigating the document, software reading the EBRF has a common way to find these indicators without needed to know the Braille code specific Braille cell representations.

Just my thoughts on this subject as someone involved in writing software to create the EBRF, may be there are use cases which need something different.

[wfree-aph]

I think the original idea was that we markup emphasis to aid backtranslation. If we don't markup emphasis, taking a file from one code to another becomes more difficult. The other aspect is that a user may choose to turn emphasis off entirely. However, I agree with the points that @jrbowden has raised and suggest that we don't track emphasis with markup in the MVP. We can always try to add it later if people object once the first spec is being reviewed.

[michaelw393]

Hi all, I've been looking at this project from the sidelines for a while and this is one of the issues that I've been thinking about quite a bit. As a Braille Transcriber I am consistently concerned about formatting as we want to reproduce the meaning (if not always the literal text) in Braille. While I'm a technical individual my background is not with markup or graphical representation programming of any sort. This is all to preface that I may not have fully understood the issue under discussion but would like to contribute.

From what I understand from wfreeman-aph's comment in agreement with jrbowden, emphasis would not be tracked using markup? Would it still be shown to the reader in the form of the Braille Unicode Patterns from the source transcription code's indicators? I assume here by emphasis what we are discussing is what the UEB rules would term 'typeforms' whether they be bold, italics, underline etc?

Would not handling emphasis in MVP run contrary to the stated aims of the eBraille project? As a transcriber I have tried to produce Word documents for use on Braille Note Touch Plus devices and the severe lack of most formatting shown by KeyWord can make navigation difficult for my readers so I am reluctant to see this project head down a similar path. How would emphasis be shown in an eBraille file that is able to be switched between Braille codes if not encoded using markup?

As for handling emphasis with contractions as the original issue raised would it not make sense to have markup indicator for which type of Braille typeform indicator would be used? I second mwhapples suggestion of a span but would suggest it not contain that code's specific typeform indicator for that situation but rather a variable that pulls from the Braille Code in use the appropriate indicator. You would specify in that span you want say a bold symbol indicator and the device would select the bold symbol indicator from the Braille Code table in use. I am only experienced with UEB so the universality of such delineations between symbol, word and passage indicators across other Braille codes is something I know little about.

This may indeed be out of scope for MVP but I think emphasis markup as a whole merits further discussion as typeforms are ubiquitous and often necessary in the texts I transcribe and that a more prescriptive approach to such indicators could would yield better flexibility and results for all who use the format.

Please let me know your thoughts

[wfree-aph]

Great points @michaelw393! I did not state my point clearly in my last comment and appreciate you weighing in and helping me realize my mistake. What I should have said was not tracking braille emphasis characters using markup. So what this would mean is that we'd still have the braille emphasis characters and we'd still have markup but the markup would not use CSS to try to add the braille emphasis characters.

I think this solution is best since we're largely relying on the transcriber to provide the braille and we are fine with hardcoding the translation in other locations, so we hardcode the braille but use markup wherever we can to aid in both backtranslation and the reader's experience generally. If we can do better in a future iteration, we will, of course, attempt it but I don't think we need anything more for MVP.

Please let me know if I've misunderstood you or if you have further thoughts here.

[michaelw393]

Thanks for clarifying that Willow and I think you got what I was saying exactly. I agree this would absolutely be sufficient for MVP. I had missed that the braille itself is already hard coded so is not exactly code agnostic to begin with! Apologies for dragging up the issue when it now seems already solved

[wfree-aph]

The current implementation in the Tagging Best Practices document is that the emphasis characters required by braille are included in the tags recommended by the specification. By including the characters, the problem should not manifest. It will depend on authors and reading systems following the recommended best practices on this issue. Closing as resolved.