Perhaps the most important part of the translation from word processor to EditWriter format is the correct translation of the line endings that are indicated at the word processor.
Word processors format text for printers, and fre-quently do so using mono-spaced characters. Occasionally, word processors can output to proportionally spaced printers, and line endings will reflect that capability. When you typeset text on the EditWriter, you want to retain only those line endings that are required-not simply the line endings that were determined arbitrarily by the need to keep words from spilling over into the word processor's right margin. Those familiar with the typesetting process, realize that the Edit-Writer will make the line ending decisions based on the font, point size, and line length specified.
Line endings are indicated by carriage returns. Word processors that transmit using the TTY protocol, will send returns for every line whether blank or not. They may also follow the return code with a series of space characters that
84
represent the left and right margins. Those that use the Bisync protocols will often send two kinds of return codes:
ordinary returns, which are translated to space by the Default Table, and required returns, which are automatically trans-lated into the return function on the EditWriter).
Required Returns An example of a required line ending is the end of this paragraph, which will not extend all the way to the right margin.
A. Required returns end short lines.
B. Required returns end paragraphs.
C. Required returns do not normally occur in the middle of a paragraph or sentence.
The required return codes that should be retained are those that appear after the heading, after the third line of the paragraph, after the end of sentences A and B, and after the second line of sentence C. In addition, the fact that blank lines were skipped with return codes is also important to know, and should be reflected in the translation.
For an EBCDIC (bisync) device, the table entries might look like this:
IV06=BCF8/ •••••••••• Return
becomes Quad Left, Tab Return IV1E=08/ •••••••••••• Non-required return becomes spaceSince ASCII (TTY) devices transmit only one type of return, the table entries might look like this:
IH
=08/ •••••••••••••••• Return becomes space
IH
=BCF8CE/ •••••••••••• Two returns become Quad Left, Tab Return, Plus Line Space
Thus a short line, or a paragraph end, would only be recognized by the EditWriter if it was followed by 2 return codes. It should also be noted that a single ASCII return (OD
hex) is automatically translated to space by the ASCII Default Table and is, therefore, not required in the Transla-tion Table.
Whenever you have a situation where a word pro-cessor or computer does not transmit tabs, you must map multiple adjacent word spaces into an EditWriter tab. When, in addition, you are receiving text that is image processed, with multiple spaces used to represent left or right margins, special table entries are needed to properly translate line end-ings. TTY table entries might look like this:
/H
=08/ ••••••••••••• Return and three spaces becomes space
/H
=08/ •••••••••••• Return and four spaces becomes space
/H
=08/ ••••••••••• Return and five spaces becomes space
Etc., up to the number of spaces required to account for the longest possible margin and indented tab.
For a bisync transmission, a series of V format translations would be required like this:
2770 or 3780
/V1E404040=08/ •••••• Non-required return and 3 spae-es becomes word spaoe /V1E40404040=08/ •••• Non-required return and 4 spaces becomes word space
Etc.
The process of handling returns properly is greatly simplified if the left margins of all documents are set to zero prior to transmission.
When copy that is primarily tabular in nature is transmitted from a word processor to the EditWriter, it useful to treat return codes differently.
When using Asynchronous (ASCII) devices, every return code (OD hex) will be translated to a Tab Return (F8 hex) and Tab (lB hex). With EBCDIC devices, a required or code return (06 hex) becomes a Tab Return, Tab (F81B)
while an ordinary return (lE or lF hex) becomes an Edit-Writer Return (29). When these translations are present in the table, you may typeset copy that looks like this:
Section
without adding tabs or tab returns at the EditWriter.
Like tabs, most word processors accomplish the centering function by embedding the copy in space codes to properly position it between margins. This applies whether the transmission was in ASCII or EBCDIC. Occasionally, a word processor will transmit a code prior to a line that indi-cates that the line is to be centered. In this case, it is possible to translate the center code into a precedence C.
The Wang word processor, for example, transmits a center code which is assigned a 20 hex value.
/V20:845C/ •••••••••• Center code becomes Precedence C The line ending code would have to reintroduce a Precedence
J
to turn off this command.Hyphenation
When receiving text from an Asynchronous word processor, there is no distinction made between required and discretionary hyphens. The Default Translation preserves all hyphens as required hyphens. When the text is rejustified on the EditWriter, many of these hyphens may need to be edited out. Alternatively, you can make a table entry that converts any hyphen that precedes a return code, to a Discretionary Hyphen. Such a table entry would be:
/H-:05/ •••••••••••••••• Hyphen and return become Discretionary Hyphen
86
Some Bisync word processors, like the Xerox 850 and IBM Office System 6, make a distinction between types of hyphens. The Default Table translates a syllable hyphen (CA hex) to a Discretionary Hyphen, and preserves required hyphens (hex value 60) as part of the text.