One of the biggest issues you will encounter is the varying quality of NIMAS files. Each project presents unusual problems related to how the electronic books were put together. We have seen enough NIMAS files to understand that publishers do not agree on how to use style tags, and files differ in how they are structured.
Computer programmers and publishing staff make decisions which affect braille transcription projects. The people who put these files together have inexact guidelines, and NIMAS filesets are designed for many uses, where braille is just one of them. Expect the quality of NIMAS files to vary from project to project.
Though there are many reasons why a file might become unreadable, a frequent cause is transmitting an unzipped archive. Here is an example. One NimPro user had an unreadable file. The original file was encoded in UTF-16. (The NIMAS standard allows both UTF-8 and UTF-16, and NimPro can read both of these formats.) However, an e-mail program used to send the XML file to the NimPro user treated the file as text, rather than as binary. The e-mail process mangled the line endings and that rendered the file unreadable in NimPro. The solution was to go back to the original zipped archive, and load that file into Nimpro instead. This is why Duxbury Systems recommends opening the original NIMAS zipped archive, when at all possible.
We have seen numerous files where the instances of math notation are rendered as graphics, requiring the transcriber to rekey a section of text. In NimPro, the Replace with Text function can help with this task for simple equations, though complex math may be better done directly in braille using the Replace with Braille function. Otherwise one can leave a marker for the image to find and edit it later in DBT or MegaDots.
You have several choices here. MegaDots has many tools for making changes in your text, such as context sensitive global replace, and numerous tools for adjusting the pattern of paragraph styles. Exporting directly from NimPro to MegaDots makes sense.
DBT is designed to work with Microsoft Word. You may find it quite helpful to export your material from NimPro into Word, edit in Word, and then import into DBT.
To simplify post-editing, one useful trick is to place markers in the NimPro file (such as "zzz") to flag places that need complex editing after you export them from NimPro.
NIMAS files are large. To address that, NimPro provides a number of "Wizards" that can be applied to recurring patterns of problems throughout as large a section of the document as you currently have selected.
Because of the way the Federal law is written, Duxbury Systems does not get to inspect NIMAS files unless the publisher explicitly allows us access. However, NimPro has a feature to render virtually all characters of a file as the letter "z" so that the file can be shared for technical support without infringing copyrights.
Problems we have seen frequently have led to enhancements in our software. For example, long print page indicators are a problem. One example file had numbers like "Review Sheet 1." In braille, print page indicators must be short, like "RS1." We have updated NimPro to assist in shortening print page indicators.
Another issue is tables. MegaDots requires tables to have the same number of columns in each row. Some NIMAS files have uneven tables which would crash MegaDots. We have updated NimPro to fill in missing cells in tables so they import into MegaDots successfully.
According to Murphy's Law ("What can go wrong will go wrong"), the data issues in the files you get may be ones that have never been reported before. You should feel free to tell us about them.
Get a look at your data as soon as possible. Hurry to obtain your data, hurry to inspect your data, and then take time to figure out how to automate issues presented by your text.
Take one section of representative text and push it through all the steps to braille. Write down any issues that you find.
Once you feel you know the issues presented with your text, you may sometimes find it easier to start over from the beginning.
Unicode is a system of encoding for all the printable characters in books. Each letter, numeral, math symbol, Chinese character, etc., has its own code in Unicode.
NimPro reads Unicode characters and displays them correctly in its main text window. NimPro's XML Viewer, however, 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. This is not usually an issue but one should be aware of it.
For braille production, you might have an issue in DBT if a character is used in an unusual way, such as a math symbol being used as a decorative element.
With MegaDots, you may have a different issue. If MegaDots does not recognize a character, it just leaves the uninterpreted Unicode in the file. For example, the Unicode value 225F appears as "~[225F]." To identify such code values, you can Google the code, e.g., "Unicode 225F," to decide what to do with it.
NimPro recognizes up to 6 levels of headings.
MegaDots supports 6 levels of headings. In the Document Menu, Heading Setup, you can tell MegaDots what to do with each level of heading.
The situation for DBT is more fluid. At the present time DBT can handle three levels of headings.
You can use the Heading Wizard in the Edit Menu to cut down the number of different levels of headings to the number you want to handle in your braille software.
When you Replace an Image with Braille, NimPro styles the braille text as "Body Text." The braille is saved in the project file and output to Word, DBT, and MegaDots. Currently, though, you cannot change the braille from Body Text style to any other style without losing the braille font styling. This affects both display and output. Once you replace an image with braille, do not attempt to change the paragraph style.