RFC 678

Standard file formats

πŸ“… published December 1974, from ietf

Standard File Formats πŸ“„βœ¨

RFC 678 πŸ’– bestie, this one is from the Network Working Group, written by J. Postel (SRI-ARC), NIC 31524, dated 19 December 1974. The header doesn't list a category, and it doesn't say this document obsoletes or updates anything. πŸ¦‹


Introduction 🌸

Okay so, the network community kept running into problems with the physical format of online documents, and it was giving chaos 😭. A big part of the issue is that the authors had no control over, or even knowledge of, all the processing steps and devices that touch the document file. We had been assuming the rest of the world was basically like our own environment, and that was the mistake πŸ™ˆ. The real problem is that everyone has different assumptions about how files get treated when they're printed as documents. So we're proposing certain standard formats for files, and we're describing what the final printed copies should look like. ✨

These standard formats are not extra File Transfer Protocol data types, modes, or structures. They're usage descriptions between the originator and the ultimate receiver of the file. πŸ’… At some hosts it might be useful, or even necessary, to build programs that convert files between common local formats and the standard formats described here. πŸ”₯

The vision is super simple: an author writes their text, stores it in an online file, and then advertises that file by name and format (as described here). That way, anyone who wants to copy and print it can fully understand the format controls and the logical page size. Iconic πŸ‘‘

Standardization Elements πŸŽ€

The things being standardized are the character or code set, the format control procedures, the area of the page used for text, and the way overstruck or underlined characters are described. πŸ’œ

Talking about the text area can get confusing, so to be clear we define a physical page and a logical page. The main emphasis here is on describing the standard formats in terms of the logical page. It's up to each site to map the logical page onto the physical page of each of their devices. 🧚

Physical Page πŸ“ƒ

The physical page is the medium that carries the text. Its height and width are measured in inches. 🌈

Typical Physical Page

The typical physical page is a piece of paper eleven inches high and eight and one half inches wide. πŸ“

The typical print density is 10 characters per inch horizontally and 6 characters per inch vertically. That gives the typical physical page a maximum capacity of 66 lines and 85 characters per line. Printing devices often limit the area of the physical page by enforcing margins, which is very relevant to your life 😭.

Logical Page πŸ¦‹

The logical page is the area that can contain text. Its height is measured in lines and its width is measured in characters. ✨

A typical logical page is 60 lines high and 72 characters wide. πŸ’–

Code Set πŸ’œ

The character encoding is the network standard Network Virtual Terminal (NVT) code, as used in Telnet and File Transfer protocols. That means ASCII in an eight bit byte with the high order bit zero. Very clean, very standard 🫢.

Format Control πŸŽ€

The format is controlled by the ASCII format effectors below. πŸ’…

Form Feed <FF> πŸ“„

Moves the printer to the top of the next logical page, keeping the same horizontal position. ⭐

Carriage Return <CR> ↩️

Moves the printer to the left edge of the logical page, staying on the current line. 🌸

Line Feed <LF> ⬇️

Moves the printer to the next print line, keeping the same horizontal position. 🧚

Horizontal Tab <HT> ➑️

Moves the printer to the next horizontal tab stop.

The conventional horizontal tab stops are every eight characters, meaning character positions 9, 17, 25, and so on within the logical page. πŸ”₯

ngl, it's hard to enforce these conventions, so it is recommended that horizontal tabs not be used in document files. πŸ™ˆ

Vertical Tab <VT> ⬆️

Moves the printer to the next vertical tab stop.

The conventional vertical tab stops are every eight lines, starting at the first printing line on each logical page. That's lines 1, 9, 17, and so on within the logical page. πŸ¦‹

Same tea here: it's hard to enforce these conventions, so it is recommended that vertical tabs not be used in document files. πŸ’€

Back Space <BS> ⬅️

Moves the printer one character position toward the left edge of the logical page. πŸ’œ

Not every effector is used in every format standard. Any effector that isn't used in a format standard is ignored. Bye bye, extra effectors πŸ‘‹

Page Length πŸ“

The logical page length is specified as a number of lines of text. 🌈

Page Width πŸ“

The logical page width is specified as a number of characters. πŸ“

Overstriking ✍️

Overstriking (note that underlining is a subset of overstriking) may be specified to be done in one or both of the following ways, or not at all. 🫢

By Line

The composite line is made up of text segments, each terminated by the sequence <CR><NUL>, except that the final segment is terminated by the sequence <CR><LF>. πŸŽ€

By Character

Each character to be overstruck is immediately followed by a <BS> and the overstrike character. πŸ’…

End of Line πŸ”š

The end of line convention is the Telnet end of line convention, which is the sequence <CR><LF>. It is recommended that <CR> and <LF> be avoided in any context other than the end of line. Keep those for the end of the line, bestie πŸ’–


Standard Formats πŸ‘‘

Format 1 [Basic Document] πŸ“˜

This format is designed for documents printed on line printers, which normally have 66 lines to a physical page but often have forced top and bottom margins of 3 lines each. 🌸

  • Active Format Effectors: <FF>, <CR>, <LF>.
  • Page Length: 60 lines.
  • Page Width: 72 Characters.
  • Overstriking: By Line.

Format 2 [Terminal] πŸ–₯️

This format is designed for use with hard copy terminals, which in the normal case have 66 lines to a physical page. There are no top or bottom margins enforced by the terminal or its local system, so any margins around the physical page break must come from the file. Main character energy πŸ¦‹

  • Active Format Effectors: <FF>, <CR>, <LF>, <HT>, <VT>, <BS>.
  • Page Length: 66 lines.
  • Page Width: 72 Characters.
  • Overstriking: By Character.

Format 3 [Line Printer] πŸ–¨οΈ

This format is designed for full width line printer output on 11 by 14 inch paper. πŸ“

  • Active Format Effectors: <FF>, <CR>, <LF>.
  • Page Length: 60 lines.
  • Page Width: 132 Characters.
  • Overstriking: None.

Format 4 [Card Image] πŸƒ

This format is designed for simulated card input. The page width is 80 characters, and each card image is followed by <CR><LF>. That means each card is represented by between 2 and 82 characters in the file. 🧚

Note that the trailing spaces of a card image do not need to be present in the file. An early <CR><LF> sequence indicates that the rest of the card image is to contain space characters. Lowkey clever 🫢

  • Active Format Effectors: <CR>, <LF>.
  • Page Length: Infinite.
  • Page Width: 80 Characters.
  • Overstriking: None.

Format 5 [Center Document] πŸŽ€

This format is meant for documents printed on line printers that normally have 66 lines to the physical page but enforce top and bottom margins of 3 lines each. The text is expected to be centered on the paper. If the horizontal printing density is 10 characters per inch and the paper is 8 and 1/2 inches wide, there will be a one inch margin on each side. ✨

  • Active Format Effectors: <FF>, <CR>, <LF>.
  • Page Length: 60 Lines.
  • Page Width: 65 Characters.
  • Overstriking: By Line.

Format 6 [Bound Document] πŸ“š

This format is meant for documents printed on line printers that normally have 66 lines to the physical page but enforce top and bottom margins of 3 lines each. If the horizontal printing density is 10 characters per inch and the paper is 8 and 1/2 inches wide, the text should be positioned so there is a 1 and 1/2 inch left margin and a one inch right margin. πŸ’œ

  • Active Format Effectors: <FF>, <CR>, <LF>.
  • Page Length: 60 Lines.
  • Page Width: 60 Characters.
  • Overstriking: By Line.

Implementation Suggestions πŸ› οΈ

Overflow 🌊

Overflow can come from two causes. The first is when the physical page is smaller than the logical page. The second is when the actual text in the file violates the standard it's being processed under. πŸ™ˆ

In either case, here are the suggestions for implementors of programs that process files in these formats. πŸ’…

Length πŸ“

If more lines are processed than fit within the minimum of the physical page and the logical page length since the last <FF>, then the <FF> action should be forced. πŸ”₯

Width πŸ“

If more character positions are processed than fit on the minimum of the physical page width and the logical page width since the last <CR>, then characters are discarded up to the next <CR>.

or

If more character positions are processed than fit on the minimum of the physical page width and the logical page width since the last <CR>, then the <CR> and <LF> actions should be forced. πŸ¦‹

References πŸ“š

A. McKenzie "TELNET Protocol Specification," Aug-73, NIC 18639. 🫢

"USA Standard Code for Information Interchange," United States of America Standards Institute, 1968, NIC 11246. 🌈

πŸ“¦ where this page comes from