kdejute

Forum Replies Created

Viewing 15 posts - 301 through 315 (of 483 total)
  • Author
    Posts
  • in reply to: Enclosed list in a superscript #30103
    kdejute
    Moderator

    Katrina,

    Thank you for the question.

    First, your comma between two items at the superscript level (within an enclosed list or not) merits use of the contracted comma. See Nemeth Code §78.

    So, for your print (Thank you for attaching an image of that lovely equation!), we should have braille that looks like this:

    ⠨⠽⠀⠨⠅⠀⠐⠨⠽⠣⠈⠱⠻⠑⠘⠊⠨⠹⠷⠭⠪⠞⠾⠐⠬⠀⠉⠲⠉⠲

    That "c.c." is spaced away from the symbol of operation that precedes it because I have good reason to believe it is an abbreviation (for cubic centimeter). I googled psi c.c. and came up with a collection of results for unit conversions using these items. More digging got me to a discussion of ψ as a unit of pressure and c.c. (or cc) as a unit of volume.

    [If we couldn't find an explanation of c.c. as an abbreviation, then it would probably still be safest to treat the print dots that are between and after the letters as periods and not as decimal points.]

    Again, thank you for the question. Please let us know if you have follow-up questions or concerns.

    Keep on rockin' that Nemeth Code!
    –Kyle

    in reply to: Spacing of Function Names #30090
    kdejute
    Moderator

    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

    in reply to: Spacing of Function Names #30084
    kdejute
    Moderator

    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

    in reply to: Numeric indicator within fraction of a function #30067
    kdejute
    Moderator

    Thank you for the question. We do include the numeric indicator for a number after a function name (the function's "argument"). Within a fraction, such a numeric indicator could not be confused with a fraction terminator, because it is preceded by a space. So, the first braille transcription in your attached document is correct.

    Cheers!
    –Kyle

    in reply to: Modified Letters #30049
    kdejute
    Moderator

    Thank you, Cindy. Attached is a document that contains my response (repeated below) to the question about modified letters.

     


    I agree that the transcription of nth or nth can be a brain twister. The transcribers at the Michigan Braille Transcribing Fund are certainly not the only ones having problems with this. Every single transcriber and group of transcribers is struggling with some aspect (or, let’s be honest, some number of aspects) of using Nemeth Code within UEB contexts.

    We are all doing what we can to provide braille readers with accurate material that is as reader-friendly and consistent (within itself and across publications) as possible. It’s a constantly evolving process, largely due to thoughtful questions like this, and it is worth it.

    In regard to “nth”:

    First, consider that transcribing an ordinal ending does not require the use of any Nemeth-Code-specific symbols. Conversely, transcribing a number or letter that is combined with a decimal, a sign of operation, a superscript, etc. does require the use of one or more Nemeth-Code-specific symbols.

    Second, mathematical significance, does not in and of itself necessitate Nemeth Code switch indicators. Words, including “plus,” “percent,” and “equals,” do not require switch indicators. Numbers do not automatically require switch indicators. Variables do not automatically require switch indicators. The mathematical constant e and the imaginary number i do not require switch indicators. Similarly, n does not require switch indicators, even when it is combined with an ordinal ending. [I expect this will be more clearly stated in the update to our Guidance whenever it is published.]

    Third, for every Nemeth-within-UEB transcription, we must trust our readers to accommodate some inconsistency, because two braille codes are being used to make the document.

    Thank you for the question. Keep on brailling on.

    Attachments:
    You must be logged in to view attached files.
    in reply to: Tables in Nemeth or UEB #30020
    kdejute
    Moderator

    Trumbull,

    It's true that the Guidance for Transcription Using Nemeth Code within UEB Contexts is not overly specific in regards to tables.

    I certainly cannot say that there is a clear dividing line between transcribing the whole body of a table in Nemeth as opposed to using one or more pairs of Nemeth switch indicators for an individual entry or entries in a table.

    I can attempt to outline a possible decision-making process for table transcription and Nemeth Code use, and I look forward to your thoughts on that. Here's that outline:

    • Does every part of the table need to be in Nemeth Code? If yes, then do it.
    • Does every part of the table's rows need to be in Nemeth Code? If yes, then insert switch indicators after the column separation line and after the last row.
    • Does every entry (not including row headings) need to be in Nemeth Code? If yes, then do as above and treat the row headings as technical material.
    • For any of the above, if the parts under consideration do not all need to be in Nemeth Code, but they are all either: a) material that needs to be in Nemeth Code or b) letter(s) and/or number(s) which could be read easily in either code, then use Nemeth Code as if all the parts under consideration did need to be in Nemeth Code.
    • If one or more table entry is a phrase or something else that is out of place within switch indicators, then experiment with using one or more pairs of Nemeth switch indicators for an individual entry or entries in a table; this may be most reader-friendly in an alternate table format.

    Does that help?

    Your questions are excellent. I look forward to your response.

    Cheers!
    –Kyle

    in reply to: Carried Number on Printed Line #30019
    kdejute
    Moderator

    Thank you, Cindy. Please pass along the following response.

    Well, that's a tough one. I have no clue as to where the advice to put the carried number in your example within the separation line might be or might have come from. To transcribe spatial problems like the example you shared (where the carried number is written/printed on top of the separation line) there is no firm right answer. Would it not be practical to braille these problems using the traditional carried number format and explain how the print differs from the braille in a TN?

    –Kyle

    in reply to: Science and UEB Blood Types and Traits #29982
    kdejute
    Moderator

    Melissa,

    Thank you for the question.

    First, for now our Guidance does not provide explicit direction for letters that represent blood types or genetic traits.

    You are right that the As, Bs, & Os of blood type and the lowercase and capital letters of Punnet squares (which represent combinations of alleles to make genotypes) are not variables. They aren't abbreviations either. They aren't even points on a graph. What are they? The letters that make up a blood type's or a genotype's "name" stand for discrete antigens or alleles. Antigens and alleles are chemical "bits" that are part of, respectively, a blood cell or a string of DNA. So, the letters we're talking about here are similar to chemical symbols for elements (e.g., O for Oxygen, H for Hydrogen, etc.).

    Do you have to transcribe the letters of blood types or genotypes within Nemeth switch indicators? I would say no. Mathematical operation is not denoted by the combination of letters representing a blood type or genotype, and the combination of letters will be easily read in either code.

    Could you transcribe blood types and genotypes within Nemeth switch indicators? Yes, you could make an argument for transcribing any letter that represents an antigen or allele within switch indicators. But I would not make that argument.

    In order to make blood types and genotypes readable, the letters of which they are made up should be individually capitalized in UEB and in Nemeth Code.

    Last, because of a technicality, I believe part of your last example must be transcribed in Nemeth Code. Because the key includes equals signs, the letters and words that are connected/compared by those equals signs must be transcribed within Nemeth switch indicators, as part of an equation.

    Rock on, and braille on!
    –Kyle

    in reply to: Variables in enclosures #29952
    kdejute
    Moderator

    Melissa,

    Your analyses of the examples you mentioned in your last post are right on target.

    Let’s be honest, it is not possible to tell at a glance whether a grouping sign is performing a punctuation role or a mathematical role; context is necessary to determine the sign’s meaning. Once you determine the sign’s meaning, you can decide whether or not to include it in Nemeth switch indicators.

    Some circumstances in which grouping signs are performing a mathematical role include:

    • solution set
    • matrix/determinant
    • enclosed list

    The most common circumstance (by far) in which grouping signs are performing a punctuation role is:

    • parenthetical aside

    Thank you for sharing your thoughts and concerns. Please keep on doing so!

    –Kyle

    in reply to: Variables in enclosures #29950
    kdejute
    Moderator
    Thank you for the thought-out question. In the example you give and in similar circumstances, the enclosed variable or number does not need to be transcribed in Nemeth Code.
       Grouping signs in and of themselves do not "modify" what they enclose. They are often merely punctuation. In other words, a variable or number enclosed in signs of grouping for purposes of the narrative text and not because an operation is being performed is not "combined" with the grouping signs the way the variable or number would be "combined" with a minus sign, a decimal point, etc.
       So, you do not need any Nemeth switch indicators for the sentence "Select the pair of inequalities that models the possible temperatures in the summer (s) and in the winter (w)."
    Please do let me know if you have follow-up comments or questions.
    Cheers!
    –Kyle
    in reply to: Nemeth and Spanish #29934
    kdejute
    Moderator

    Thank you for the question and the supporting documents. Your concern is understandable.

    First, I agree with you wholeheartedly that the "and"/"y" as well as the "or"/"ó" are part of the mathematical expression and not part of the narrative text. So, for that reason, the single-word switch indicator is inappropriate.

    Second, I would also not use the single-word switch indicator for the Spanish symbol for an accented o, because the single-word switch indicator signals that what follows is a UEB symbol, and the one-cell symbol for the accented o is a Spanish Braille Code symbol.

    Third, if the Spanish Braille Code symbols "y" & "ó" are transcribed within Nemeth Code switch indicators without any additional indicators, then they technically only have the meaning of their respective dot configurations in the Nemeth Code. Thus, the "y" is the 25th letter of the English alphabet, and, more troublingly (as you say), the Spanish Braille Code symbol "ó" is a plus sign.

    We are left trying to use Spanish Braille Code symbols within a Nemeth Code context, and that is a no-win situation.

    So, since we've got to do something, I would go with your first suggestion, under "Spanish uncontracted," because it is probably the least likely to be misread. Thus, we get:

    ,si ,a y ,b son sucesos traslapados1
    entonces _% ,p(,a + ;,b)
    .k ,p(,a)+,p(,b)-,p(,a y ;,b) _:4

    Please note that the ELI is not used with the As that are only in contact with one grouping symbol, because if that opening paren were not there, then the A would be unspaced from the P. This is in line with Nemeth Code section 28.a's directive that when one letter is in direct contact with only its opening or only its closing grouping sign, the English letter indicator must be used or must not be used as though the grouping sign were not present.

    Regardless of how you handle this Nemeth-Spanish conundrum, a transcriber's note is in order, I think. Perhaps something like: Spanish language words "y" as well as "ó" are used within the following equation.

    I hope that either my thought process or my suggestion are helpful to you. Thank you again for the question.

    Braille on!
    –Kyle

    Attachments:
    You must be logged in to view attached files.
    kdejute
    Moderator

    Diana,

    Thank you for the question. In short, yes, what you describe is a complex fraction, because it has a fraction within a fraction all on the baseline level.

    Please see section 65 of the Nemeth Code. Also, attached is an image of what it sounds like your print looks like as well as a .BRF and a WORD document that contain an appropriate Nemeth Code transcription of that print.

    –Kyle

    • This reply was modified 6 years, 6 months ago by kdejute. Reason: Add more information and related files
    Attachments:
    You must be logged in to view attached files.
    in reply to: insert space after commas in enclosed lists? #29781
    kdejute
    Moderator

    Greta,

    Yes, there should be a space following a comma in an enclosed list in Nemeth Code.

    See the examples (especially 4 and 8) under section 41.a of the Nemeth Code.

    –Kyle

    • This reply was modified 6 years, 6 months ago by kdejute. Reason: Nemeth Code reference for required space following a mathematical comma found
    in reply to: Tables in Nemeth or UEB #29779
    kdejute
    Moderator

    Yes, I would do as you describe.

    _% (ft^2") _:

    –Kyle

    • This reply was modified 6 years, 6 months ago by kdejute.
    in reply to: Tables in Nemeth or UEB #29775
    kdejute
    Moderator

    Greta,

    Thank you for your questions.

    #1: Yes, for a table that consists of nothing but words and unmodified numbers, it's UEB all the way.

    #2: A table that has one entry that must be in Nemeth Code is not required to have all its rows in Nemeth Code. In the example you provided (where a row heading and an entry both include material that must be in Nemeth Code and there are no column headings) I think I would suggest transcribing the body of the table all in one Nemeth bubble, with the opening Nemeth Code indicator in cell 1 on a line by itself right before the first row and the Nemeth Code terminator in cell 1 on a line by itself after the last row of the table. But I do not believe it would be wrong to enclose the fraction in the row heading in one set of Nemeth Code switch indicators and the fraction in the second column in another set of Nemeth Code switch indicators.

    #3: Our Guidance does not require that (x) in "Number of Sheets (x)" be transcribed in Nemeth Code. So, there is no technical material in the column headings of the third example table you shared. You're quite right that the decimals that make up the second column's entries must be in Nemeth Code. So, you should enclose the row headings and table entries in one Nemeth bubble, with the opening Nemeth Code indicator in cell 1 on a line by itself following the column separation lines and the Nemeth Code terminator in cell 1 on a line by itself after the last row of the table.

    Thank you for your questions! Please let me know if you have any follow-up concerns.

    –Kyle

Viewing 15 posts - 301 through 315 (of 483 total)