NimPro provides a number of features to help you resolve issues that can arise in NIMAS files.
NIMAS file sets are designed for many uses, including talking books, large print, and braille. In practice, publishers, and the services they may employ to create the NIMAS versions of their textbooks, mostly make production decisions without regard to the requirements of braille transcription.
Moreover, individual NIMAS documents vary widely in how - and how well - they apply the "Digital Talking Book" Document Type Definitions (DTD), i.e., the set of rules created by the DAISY Consortium. Publishers do not agree on how to use certain style elements in the Digital Talking Book definitions, and NIMAS files differ in how well they follow the prescribed structure.
Duxbury has built significant "intelligence" into NimPro so that it can recognize some of these variations and produce reasonable documents from them. However, issues will remain for the braille producer to solve. You are encouraged to let Duxbury know about the most significant problems you find, so that future versions of NimPro may be able to address them.
In general, NIMAS files that are sent electronically from place to place are much more likely to get to the destination intact if they are sent in their original zip archive format.
Email programs are notorious for causing attached documents to be garbled in transmission. Other methods of electronically transmitting documents can do likewise if they attempt to interpret the document as text. "Zipped" documents usually fare better than other formats, and Duxbury recommends keeping NIMAS documents in the zip archive format to transmit them.
Unicode is a uniform system of encoding the characters in printed materials that covers most of the world's languages. Each letter, numeral, math symbol, Chinese character, etc, has its own code in Unicode.
NimPro writes its internal documents in Unicode. When reading a NIMAS document it can interpret several Unicode formats (including UTF-8 and UTF-16) as well as several other common code page formats that preceded Unicode (such as Windows-1252) as long as the code page is correctly identified in the document header. Fortunately, the header provides a place to look if NimPro cannot read your particular document.
NimPro reads Unicode characters and displays them correctly in its document view window, subject only to the limitations of the font selected for display. (The Cambria font has generally good coverage and is the normal font NimPro uses.)
NimPro's XML Source File Viewer, on the other hand, can display only the normal range of ASCII characters, and the higher-order Unicode characters in the source file are not visible through that function unless they are encoded as entity references. Fortunately, this is not usually an issue, but one should be aware of it.
For braille production, you might have to make edits in NimPro or DBT if a character is used in a non-standard manner, such as using a math symbol as a decorative element.
In modern textbooks there are often instances where text has been rendered using an image format because of its two-dimensional complexity. This is especially common with mathematics books, where the math notation is rendered in a graphic image, requiring the textbook transcriber to re-key significant portions of the text - to render the math equation into braille.
In NimPro, the Replace with Text function can help with this task, especially for single-row equations. Alternatively, complex math may be done directly in braille using the Replace with Braille function.
With the advent of MathML (the extensible markup language for math) the situation is much improved. Some NIMAS math documents that use MathML include each math expression two ways, first in an image and immediately afterwards in MathML markup. This is quite helpful. The image makes the intent of the MathML clear for the NimPro user, and NimPro interprets the MathML automatically to produce the correct markup for braille math.
Print documents tend to use many more levels of heading than braille documents. You can use the Heading Wizard to cut down the number of different levels of headings to the number you want in your braille.
When you replace an image with directly entered braille, NimPro styles the braille paragraph as "Body Text" and embeds a "braille font" attribute to identify it. The braille is saved in the project file and output as direct braille to Word and DBT. However, you cannot change the braille paragraph to any other paragraph style without losing the braille font styling for both display and output.
Once you replace an image with braille, do not attempt to change the paragraph style.
Most of the features in NimPro are responses to the problems inherent in NIMAS files. Here is a "grab bag" of problems solved, partly-solved, and how to get help solving others.
NIMAS files are large. NimPro provides a number of "wizards" that can be applied to recurring patterns of problems that may occur throughout your document. These wizards can be applied to the entire document, or to specific portions of the document you currently have selected, even if they are not contiguous.
Overly-long print page numbers used to be a problem. One example Duxbury encountered had numbers like "Review Sheet 1", "Review Sheet 2", etc. In braille, print page indicators must be minimal length, like "RS1". In response, NimPro now automatically detects and shortens overly long page numbers. It also allows you to edit page numbers manually just like normal text.
Another problem that is now resolved is badly constructed tables. Some NIMAS files actually have tables with uneven numbers of data cells in different rows. We have enhanced NimPro to fill in missing cells in tables so they can be handled successfully.
The Federal law that created the NIMAC prevents companies like Duxbury Systems from inspecting a NIMAS file unless the publisher explicitly grants access. To respect that, NimPro has a "scrambler" utility you can run that masks document content so that you can share a problem with us to try to get a solution. The scrambler retains all the structure of the document, but it renders the majority of the text, virtually all the characters of the file, as the letter "z". Once masked, the file can be shared to get technical support without infringing a copyright.
According to Murphy's Law ("What can go wrong, will go wrong"), you may encounter problems never reported before. Please, feel free to tell us about them.