[kdejute]

...

• This reply was modified 5 years, 11 months ago by kdejute. Reason: remove duplicate post

[kdejute]

Shelley,

Thank you for the questions.

Grouping symbols around fractions that are transcribed spatially are not enlarged [because they do not enclose multiple separate rows of information]; they are transcribed using simple one-cell grouping symbols on the braille line with the fraction indicators and fraction line.

See the fraction transcribed spatially in the denominator of the second example on page 79 of the Nemeth Code [section 68’s example (3)].

In response to your second question, section 60 of the Nemeth Code says in part, “Items which are individually canceled in ink print must be represented as individually canceled in the transcription.” Unfortunately, there is not a way to transcribe your print’s one long strike that cancels both one fraction’s denominator and a separate fraction’s numerator. So, yes, simply cancel each appropriate numerator or denominator on its own.

Braille on!

–Kyle

 

[kdejute]

Trumbull,

This can be tricky, and, like you, I cannot point to a rule that specifically addresses blanks in a Nemeth-within-UEB transcription.

I *can,* however, affirm that it is inappropriate for the transcriber to give more information than the print does about what an answer should/will be like.

What I’m trying to say is, transcribe a low-line/omission dash/underscore according to where it appears in print and NOT what will/should replace it.

So, in your (very illustrative!) examples:

The low line that is part of a math expression (involving the “is congruent to” symbol) should be in Nemeth Code.

The low lines following the words “corresponds to” should be in UEB.

Really, I would put the low line in the sentence “So <fraction> is ____.” in UEB ... following the reasoning that the braille reader is getting the same information as the print reader from the instructions “The answer will be in decimal form.” and to transcribe the low line in Nemeth Code would be overkill.

Of course, this doesn’t solve all of our dilemmas, but I hope it shrinks some of them.

... Please let me add that I would transcribe consistently in Nemeth Code a <b>shape</b> that stands for something missing within a math expression and is then repeated and asked about outside of a math expression.

–Kyle

 

[kdejute]

In item #5, where print uses squares to indicate a missing something in a mathematical expression, we’ll use the Nemeth square shape, as you say. With the goal of giving the reader consistent symbols, we’ll also use the Nemeth square for the other square, after “value of”.

The shapes that precede each answer choice are not part of the meaning of the text. I would omit them in braille or use a transcriber-defined shape for these squares. (The “transcriber-defined shape” is explained in the Rules of UEB, and the Guidance for Nemeth within UEB says it can be used both in UEB and between Nemeth Code switch indicators.) Whether you omit the squares before answer choices or transcribe them using a transcriber-defined shape, you’ll be giving the braille reader the same thing at the beginning of every answer choice.

Thank you for the questions! Please do let us know if you have more.

–Kyle

[kdejute]

Here is an image file of the above BRF.

Attachments:

You must be logged in to view attached files.

[kdejute]

We can point to no rules that specifically address Pascal's triangle.

If possible, it would be appropriate to follow print's triangular layout of a representation of Pascal's triangle. The content of the triangle determines which code (Nemeth or UEB) will be used.

Since we're talking about a transcription using Nemeth within UEB, in your sample of print, the triangle made up of C's with subscripts must be transcribed in Nemeth Code, and the triangle made up of whole unmodified numbers may be transcribed in Nemeth Code or in UEB.

Attached is a BRF with both triangles from your sample print transcribed, with the longest row (i.e., the base) of the triangle beginning in cell 1 and each smaller row centered relative to the row below it.

–Kyle

• This reply was modified 6 years ago by kdejute. Reason: full answer replaces "answer pending" response

Attachments:

You must be logged in to view attached files.

[kdejute]

Shelley,

It appears that what you have in your item 6 is a stem followed by a displayed bulleted list of non-technical material and a series of subitems. So, the correct formatting is probably 1-5 for the stem, 7-9 with blank lines before and after for the bulleted list, and 3-5 for the subitems.

Thank you for the question!
–Kyle

[kdejute]

Shelley,

Please let me preface with: There is no written-in-stone answer to your questions.

1. If the main stem is in 1-5 with the lettered problems in 3-5, I would suggest treating the "Solution" and "Explanation" as additional paragraphs within a subitem, thus formatting them in 7-5.
2. The most straightforward approach to transcribing what comes after "Solution:" and "Explanation:" is to follow print, i.e., use an underscore after "Solution:" and nothingness after "Explanation:".

–Kyle

[kdejute]

Keith,

Orbital names such as 1s, 2s, 2p, etc. do not require Nemeth Code. In addition, we do not retain italics for the letters in orbital names. As you say, wherever a superscript is included, Nemeth Code is certainly required (with italics still ignored).

–Kyle

• This reply was modified 6 years ago by kdejute. Reason: answer confirmed; language changed to reflect that

[kdejute]

Good day, Tung!

I had no trouble seeing your simbraille, and I appreciate your posting here with both the print and a proposed transcription.

As I understand it, your questions are:

1. Is it appropriate to use a transcriber-defined typeform for circled words?
2. Is it appropriate to use bold within a problem arranged spatially for calculation?
   • If not, then how might I transcribe numbers that are somehow set apart/emphasized in a problem arranged spatially for calculation?

 

1. Yes, I support and condone your use of a transcriber-defined typeform in UEB for circled text. This is in line with Braille Formats 2016 §5.9.
2. Although it is not directly supported by the Nemeth Code to use Nemeth bold for numerals within a spatial problem, your solution (including alignment which puts each bold indicator and its associated required numeric indicator in columns of their own) does seem readable and accurate.

Yes, I too would use the Nemeth Code's general omission indicator for a blank "box" in a problem when that box indicates a missing numeral (NC §58).

One additional note: The separation line which appears in an addition problem must be made one cell longer at either end than the overall width of the rest of the arrangement. (NC §178.c) So, I would make the line above the total in your example one cell longer.
Conversely, the column separation lines for "Tens" and "Ones" columns should be just the width of the column they head (BF2016 §11.4.2.b) [with the possible exception of letting your "Tens" column heading and separation line begin in cell 1].

Again, thank you for posting; and thank you for your time!
–Kyle

[kdejute]

Shelley,

I would look to both the example under Nemeth Code section 178.g and the text of Nemeth Code section 27.g for reasons to *not* use the English Letter Indicator in problems involving variables arranged spatially for calculation. That still doesn’t give you language that says not to use the ELI for variables in a problem arranged spatially, but I think those pieces effectively define the *lack* of a requirement for ELIs in problems arranged spatially for calculation.

As always, thank you for the question, and please do not hesitate to post follow-up questions/concerns.

–Kyle

[kdejute]

Cheryl,

That's a considerate follow-up question.

In fact, in many print environments the hyphen and negative sign are the same. Both the print and the braille reader must use context and experience to determine whether the symbol they're reading is a minus or a hyphen.

Section 45 of the Nemeth Code (on page 51 of the "green" book) says, "§45 Hyphen: The hyphen is represented by the same sign of ink print as the minus sign. Since the corresponding braille symbols also coincide, a minimum of decision-making in this regard is required of the transcriber.  ..."

–Kyle

[kdejute]

Hmmm ... I do not see the significance of the lines you describe. Perhaps the publisher’s website includes an “About the Book” section or other commentary that might shed light on this design.

If the lines aren’t mentioned, and you don’t find a pattern of which tables have which lines, I would be tempted to ignore them.

–Kyle

[kdejute]

I expect it’s quite alright to have upper-cell numbers in Nemeth and UEB, even having a mix as in your example. Bending over backwards in order to have every number of a numeric key in Nemeth Code is unnecessary and potentially confusing to the reader – It might make them ask, “Wait!??! What’s mathematical about this??”

So, it is not necessary to treat the upper-cell numbers as Nemeth Code when listing the keyed labels. Thank you again for the question.

–Kyle

[kdejute]

Trumbull,

I hear you! In fact, as I understand it, you may use upper-cell numbers in a Nemeth numeric key.

The Guidance says that we may not use UEB symbols within Nemeth Code context, but upper-cell numbers within a Nemeth numeric key are in fact Nemeth Code symbols from the Nemeth Code even though they have the same dot configurations as UEB numbers.

So, make sure your key listing is clear, including, as always, using the same symbol in your key listing and in the graphic/table, and you should be good to go.

Sense make?

–Kyle

[Author]

Posts