Keying a table Nemeth/UEB

[togilby]

I'm looking for clarification about keys in key listings. In the attached example, I've used x(subi), y(subi), etc as my keys. The 2nd and 3rd keys are not within Nemeth switches but to my mind, in a key listing, the key is nothing more than a symbol which represents something and therefore loses all other meaning it might have in another context. Am I on the right track? I realize I could use upper cell numbers to key the headings but the 3-cell "math" keys would actually be indicative and useful! Any insight or direction appreciated!

trumbull

Attachments:

You must be logged in to view attached files.

[kdejute]

Response coming soon ...

• This reply was modified 4 years, 7 months ago by kdejute. Reason: incomplete response removed

[Lindy Walton]

Hi. Thank you for your example. Brailling tables is a challenge. It is always worth the time to stand back and think about the best way to convey the information in a straightforward manner. I'm glad you brought this one to our attention.

Let's take a new look at this table.

First, to answer your question about using math items in a key, Braille Formats instructs us to use two- or three-cell numbers, letters (with certain restrictions), or letter-number combinations in a key. Those letters and numbers are in UEB.

Another option is to condense, shorten, or abbreviate the long items. In that case, you would list the abbreviation followed by its meaning (if it is not obvious). Then, yes, you would need to show the math portion of the shortened or condensed version inside Nemeth Code switches. I would not mixed condensed items in the same list as keyed items.

It is always a better idea to see if you can fit the column heading in the available space rather than condensing or keying. In this case, it works well! Check out the BRF file attached to see how you need to key only three of the column headings.

I found your long TN difficult to transfer into my ability to read the table. I like being able to read the table up and down and sideways, as a table is read, without having to delve into a TN to recall what is missing. In the attached BRF file, I show all the figuring done in the "Austria" row, as printed, in a list before I braille the table.

I was able to fit the final computation within the confines of column six, following the runover rules of the Nemeth Code. (I separated this from the main body of the table with a
blank line.)

Note also the BF 11.14.1 says "the preferred format is to place the table on facing pages" so I have shown this layout, but if this is not an option for you there is still plenty of room to repeat your first column as row headings on the second page of the table. If that is your method, I recommend using the wording given in BF for your TN" "Table is divided vertically into 2 sections." If you decide to use facing pages, be sure the first page falls on a left-hand braille page.

I changed the footers to comply with BF 11.3.2.b.

There is a current discussion regarding the use of the symbols for countries as established by IOS (see Appendix C of our Tactile Graphics Guidelines) even though some of them do not comply with the restrictions given in Braille Formats for letters in keys. I did use those symbols in the attached file.

.. Lindy Walton

Attachments:

You must be logged in to view attached files.

[togilby]

Thank you, Lindy, this is very helpful as the book contains many of these tables with example computations in the first row. I will happily employ your practical method of listing the 1st row entries before displaying the complete table. And I appreciate your cross-references to specific Formats guidelines.

trumbull

[Author]

Posts