See Also: Formatted Braille Importer...
(This topic is reproduced from DBT's original "Topical Guide")
These are some hints on successfully importing formatted braille (BRF) files, which frequently give rise to questions.
"BRF" (pronounced "brif") files are Duxbury's long-standing term for a simple file format that, with some minor variations, has also become something of an industry standard. BRF files are really just ASCII text files that represent finished braille pages, line by line and page by page, using the North American ASCII-braille convention to represent the braille cells. Such files are the normal output of older versions of DBT, are produced and edited directly by Duxbury's older DOS-based "Edgar" braille editor (currently released to limited freeware), and are also produced by other products and editors such as Polkadot. (MicroBraille files are not BRF files, but MicroBraille includes a utility to convert its own file format into BRF files. So, if you need to import MicroBraille files, use that utility first and then import the result as a BRF file.)
The BRF format is so simple, you might think that importing would also be very simple--and it is, once you catch on that you must first supply some information that is not technically present in the file itself. That is because the import process attempts, just as with all the other imports, to create a DBT file that can be edited further--not just an image of the original file that is faithful to that exact form but rigid and useless for changing to any other form. (We will come back to the case where change is not an issue and rigid fidelity to the original form IS paramount--but for now, please accept the premise that the possibility of further editing, or at least reformatting--say, for different page dimensions--is desirable.) In order to permit sensible further editing, DBT must correctly identify such structural elements as running headers and footers, centered headings, paragraphs, etc. and code them accordingly. The problem is, the file itself does not contain that information but only the "page images", i.e. the result of a formatting process without any "memory" as to how and why it got that way. DBT must therefore reconstruct the information, based upon information that you give it.
An example might help. Let us say that a particular BRF file contains running headers. If you tell DBT (in the Global/Formatted Braille Importer dialog box) that there are headers on each page, DBT will know enough to mark any new text on the top line as a running header (i.e., surround it by [tls] ... [tle] codes), and will completely ignore any such text that is the same as the header on the previous page. But if you don't tell DBT that running headers are present, DBT will presume that there is nothing special about text on the top line, and will treat it as just a continuation of the body text from the previous page. The difference in treatment will become immediately apparent if you add or subtract a few lines of text somewhere: in the first case, the true body text will re-flow sensibly from or to the following page, leaving the running-head properly where it is, whereas in the second case the running-head would move along with the adjacent body text, winding up in a nonsensical position.
When you consider not only running headers but running footers and both the braille page number and the print page number--all of which can be present or not and sometimes in different positions, and the fact that a BRF file doesn't show any of them any differently from regular body text--it is apparent that DBT needs accurate information about the layout of the BRF file in order to do the import properly.
You give that information, that is a description of the BRF file AS IT IS, in the Global/Formatted Braille Importer dialog. The quality of the import will depend critically on that description being accurate, as we have seen. Among other things, the description asks for the page dimensions. The width must be exactly correct in order for DBT's sensing of centered headings and right-hand page numbers to work properly. The only leeway is in the depth, which must be at least as large as the actual depth--but, usually, can be larger without any harm coming of it. That is because most BRF files (except for very old ones, from the 1970s) do contain explicit markers at the end of each page.
If you do not know all the required information about the BRF file to be imported, simply make your best guess, do the import, and inspect the result to see if some parameters need to be changed. If so, discard the imported file, adjust the Global/Formatted Braille Importer dialog accordingly, and re-import.
Incidentally, the "as-it-is" description that you give in the Global/Formatted Braille Importer dialog might or might not be the same as you want the eventual file to be--as defined by the current desired braille page dimensions in the Global/Embosser Setup dialog and the page layout in the Document/Page Numbering dialog. They may well vary; in fact, reformatting may well be what you have mainly in mind when importing. Nevertheless, if you are at all unsure about the description that you are giving for the existing BRF file, it is generally less confusing to have both sets of descriptions in agreement at the time of the import, so that you can easily verify that everything has come in correctly in the first place; you can then change whatever you want in the Global/Embosser or Document settings.
Now let us return to the question of whether such imports can be "perfectly" faithful to the original BRF file in all circumstances. If the "as-is" description is accurate and the current page dimensions and other settings are in agreement, it very frequently happens that the import is perfect in that sense--but, as things stand, it cannot be guaranteed. That is partly due to some slight (and generally useful) leeway in the input sensing. For example, an input line that is centered with a "right bias" might be marked as centered, which could cause a 1-cell shift when it is re-centered, but with "left bias", in the output. Another possible source of discrepancies can occur when page depths vary slightly, as is permitted in a BRF file but is not possible in DBT's output.
That does not mean that users wishing for perfectly-faithful BRF imports are wrong. That kind of import makes good sense when one has existing libraries of BRF files that are known to be correct, and one simply wants a consistent way of embossing them as they are--no change at all is anticipated or wanted. If that is what you want to do, simply check the box labeled "Read formatted braille without interpretation" in the Global / Formatted Braille Importer dialogue. Then, all other options in that dialogue will be disabled, i.e. they cannot be set as they will have no effect. The import will then treat all spaces, line breaks and page breaks as to be preserved without change, and as long as the page dimensions in your Document settings are at least as large as those implied in the incoming file and all page numbering is turned off, the braille page images should match exactly the contents of the original BRF file exactly. As explained above, this should work fine for embossing, but not at all well for other purposes such as re-flowing for a different page size, changing the braille in any way, or translating to print.