Spacing of Function Names

[rroldan]

I have run into something that seems ambiguous in the UEB code that I could use some clarification on. I am working on a Precalculus book where the functions have an obvious space between the symbols before and after the function names.

sin θ = y/r
sin 1/2θ = x/y
1/2ab sin θ = ½(10)(3) sin 1200
sin A =2bc cos A

The UEB Guidelines for Technical material section 9.3 seems to clearly cover what to do if the material is unspaced but I am seeing varying interpretations of what to do when a space is already present in print. I am of the belief that none of the rules explicitly say to eliminate a blank space shown in print, therefore, we follow print (UEB 2.3) and maintain the blank spaces as they appear in the text. I have interpreted that the provisions below only apply when the material is unspaced and ambiguity can occur.

9.3 Where the function name is preceded or followed by a letter, a space may be needed, to remove ambiguity as to where the function name begins and ends.
(I interpret this to mean unspaced letters because if they are already spaced we wouldn’t need to add a space).

9.3.1 If a function name is directly preceded or followed by a number, then the number should be written unspaced.
(I interpret directly preceded to mean no blank space shown in print because if there were a blank space and we were to omit it the code should say “with or without a blank space shown in print” so that we know that we are to remove the blank space if one is shown.)

9.3.2 Insert a space if a function name is followed directly by a lower case Latin letter with no intervening braille indicators or brackets.
(I interpret this to mean no blank space shown in print because if they are already spaced we wouldn’t need to add a space)

9.3.3 Insert a space if a function name is preceded directly by a lower or upper case Latin letter with no intervening braille indicators or brackets. Note that letters isolated by these extra spaces may need grade 1 indicators.
(I interpret this to mean no blank space shown in print because if they are already spaced we wouldn’t need to add a space.)

I have seen braille and heard from other transcribers that spaces shown in print before or after all Functions are to be removed unless one of the rules above applies.

I always want to support my decisions based on the code and want to do this correctly. So I have been looking for examples of functions that are clearly spaced (because all of the ones in the Guidelines for Technical Material appear to be unspaced or are spaced both in print and braille). I have only been able to find 1, in your NBA manual “Using UEB in Technical Materials” article I found the attached examples which further confused me.

The Greek theta in item 1 appears to be spaced in print but they unspaced it in braille. While the capital A in item 3 is unspaced in print and it is also unspaced in braille. If my understanding of the rule, that we follow print, is correct then the theta should be spaced just like the A is. Otherwise, the capital A should be unspaced because the capital symbol removes the ambiguity.

My question is, do we remove all the blank spaces before and after the function names and apply the rules in 9.3 or do we follow print and only apply the rules in 9.3 when the print shows the functions unspaced and the ambiguity covered in these rules occur?

Thank you for your time and assistance with this matter.

Attachments:

You must be logged in to view attached files.

[Jonathan Carson]

This issue has caused me no little consternation as well. In the Guidelines, in 9.3.2, for "Sec  A," there is a space between the "Sec" and the "A." However, it is not easily (read: visually) apparent. One can only discern this by putting the cursor in the actual PDF and pressing the right arrow button over to reveal it. In the translation below it, the space is removed in the braille. I have been basing my spacing rules for functions and capital letters/Greek letters upon this sole example. If this is inaccurate, please let me know.

[Jonathan Carson]

To further muddy it, "sin(A+ B) = sin AcosB+cos Asin B" in 9.3.3 likewise appears to have spaces after "sin" and "cos" in the print file which have been removed in the braille translation.

[kdejute]

Thank you for your questions about using UEB to transcribe technical material, specifically function names.

First, the Guidelines for Technical Material simply tell us, "Spacing should be used to reflect the structure of the mathematics. Spacing in print throughout a work is often inconsistent and it is not desirable in the braille transcription that this inconsistency should be preserved." (1.1.1) So, unless the print is very consistent with its spacing, we should remove spacing around function names except where spacing is necessary to avoid ambiguity.

---

You are correct that 9.3 deals with letters that are unspaced in print from the function name (especially Latin letters immediately preceding a function name and lowercase Latin letters immediately following a function name). 9.3 also deals with letters whose spacing in print around function names is not perfectly consistent, which is the vast majority of situations. Sections 9.3.2 & 9.3.3 also deal with letters that are unspaced in print from the function name as well as with letters whose spacing in print around function names is not perfectly consistent

9.3.1 does in fact mean that a number which immediately precedes or immediately follows a function name, with or without a blank space shown in print, should be brailled unspaced from that function name.

---

In regards to the items from NBA's workshop/manual "Using UEB in Technical Materials":

• In item #1:
  • The number must be brailled unspaced from the function name that it immediately follows.
  • The lowercase Latin letter must be brailled spaced away from the function name that it immediately follows.
  • The lowercase Greek letter theta should be brailled unspaced from the function name that it immediately follows (except perhaps in the case where print is very consistent with its spacing), because the Greek letter indicator removes the possibility of ambiguity.
• In item #2:
  • The lowercase Latin letter must be brailled spaced away from the function name that it immediately follows.
• In item #3:
  • The capitalized Latin letter should probably be brailled unspaced from the function name that it immediately follows, because the capital indicator removes the possibility of ambiguity. Well spotted.

 

It is a constant process to hone our understanding and application of braille rules and to update our materials to reflect that process. Thank you sincerely for being part of that process by sharing your questions and notes on NBA materials.

–Kyle DeJute

[rroldan]

Thank you for your fast response.  Unfortunately I am even more confused than before, because you say to follow print when a blank space is clearly (and consistently) shown in the text, but you later say to remove the blank space for numbers.  Nowhere in the rules does it explicitly say to remove spaces for numbers or any of the other symbols.  In all of the rules they use the terms:

directly preceded or followed by a number

followed directly by a lower case Latin letter

preceded directly by a lower case or upper case Latin letter

To me this means that there are no blank spaces in the print and this is what you need to do to eliminate any ambiguity that can occur when material is unspaced.  To infer that they mean to remove blank spaces when it is not stated, and none of the examples for numbers are spaced, is very confusing to me because it then opens up another series of questions:

Do we unspace clearly spaced fractions because they contain numbers?

Do we unspace numbers inside of signs of enclosures when they are clearly spaced?

Do we unspace numbers inside of clearly spaced radical signs?

Examples of these questions are shown in the examples at the beginning of my first inquiry.  Wouldn't it make sense that they would have explicit rules telling us what to do for all of these situations when a blank space is shown in print if they needed to tell us what to do for numbers?

Finally, is there some way to communicate directly with the BANA Math Committee (or is that what you do for us) to find out what they meant by these rules and whether or not they are going to amend them to resolve this ambiguity as well as include clearer examples of what to do with both spaced and unspaced examples?

Thanks again for your time and assistance with this matter.

[kdejute]

Before we go too deep down the rabbit hole, let's tackle the terms that you highlighted:

• directly preceded or followed by a number
• followed directly by a lower case Latin letter
• preceded directly by a lower case or upper case Latin letter

May I propose that instead of meaning "unspaced in print", these terms mean "without an intervening symbol or indicator in braille" (e.g., capital indicator, grouping/enclosure sign, alphabet indicator, level indicator, fraction indicator, etc.)? If that is the meaning of these terms, does that affect your confusion?

---

You may send a message to BANA's General Committee on UEB through the link at the very bottom of BANA's homepage.

Thank you for sharing  your thoughts! I look forward to your response.
–Kyle

[rroldan]

I took your advice and contacted both BANA and ICEB.  Below is the answer to our question regarding section 9.3 of the GTM.

 

Your primary thought to follow print is correct in my estimation.  As you have noted, math often is not precise in it's use of spacing in print.  They may use "half" spacing or may present equations across the print line, expanding or contracting the spaces to allow it to fit.  The aim is to ensure legibility for the reader.

 

In the same way, in braille, we want to ensure that the braille is unambiguous (RUEB 1.2.2).  RUEB 1.2.3 states that "the primary transcribing rule is to produce braille that, when read, yields exactly the original print text (apart from purely ornamental aspects)".  In maths, "spacing should be used to reflect the structure of the mathematics" (GTM 1.1.1).

GTM 9.3 was written to illustrate how spacing of function names can be used to remove ambiguity when dealing with function names that are unspaced in print (or where the spacing is uncertain, as with half spaces).  It is only when the function names are unspaced that there is possible ambiguity.  If print uses spaces to set them apart it is correct to do so in braille as well.  The resulting braille will not be ambiguous in any way.

They concluded by saying that removing the blank spaces when they are clearly shown in print doesn't affect the reader's ability to use the braille but is does deviate from the preferred method of following print.

Hope this helps.

 

[kdejute]

Thank you for sharing here your conversation with the BANA General Committee on UEB. Now we can all take the reasoning they explained into account when investigating print and generating braille.

Sincerely,
Kyle

[Author]

Posts