Rich Text Format (RTF) Version 規格 1.5 - 2

Character Text

Character text has the following syntax:

Font (character) Formatting Properties

These control words (described as <chrfmt> in the syntax description) change font (character) formatting properties. A control word preceding plain text turns on the specified attribute. Some control words (indicated in the following table by an asterisk following the description) can be turned off by the control word followed by 0 . For example, \b turns on bold, while \b0 turns off bold.

The font (character)-formatting control words are listed in the following table.

The following table defines the standard languages used by Microsoft. This table was generated by the Unicode group for use with TrueType and Unicode.

To read negative \expnd values from Word for the Macintosh, an RTF reader should use only the low-order 6 bits of the value read. Word for the Macintosh does not emit negative values for \expnd. Instead, it treats values from 57 through 63 as -7 through -1, respectively (the low-order 6 bits of 57 through 63 are the same as -7 through -1).

Character Borders and Shading

Character shading has the following syntax.

The color, width, and border style keywords for character borders are the same as the keywords for paragraph borders.

Associated Character Properties

Bidirectional-aware text processors often need to associate a Latin (or other left-to-right) font with an Arabic or Hebrew (or other right-to-left) font. The association is needed to match commonly used pairs of fonts in name, size, and other attributes. Although RTF defines a broad variety of associated character properties, any implementation may choose not to implement a particular associated character property and share the property between the Latin and Arabic fonts.

Property association uses the following syntax:

Here are some examples of property association:

\ltrch\af2\ab\au\rtlch\u Sample Text

This is a right-to-left run. Text will use the default bidirectional font, and will be underlined. The left-to-right font associated with this run is font 2 (in the font table) with bolding and underlining.

\plain\rtlch\ltrch Sample Text 

This is a left-to-right run. The right-to-left font and the left-to-right font use the default font (specified by \deff).

\rtlch\af5\ab\ai\ltrch\u Sample Text

This is a left-to-right run. The right-to-left font is font 5, bold and italicized. The left-to-right font is the default font, underlined. If the reader does not support underlining in the associated font, both fonts will be underlined.

The property association control words (described as <aprops> in the syntax description) are listed in the following table. Some control words (indicated in the following table by an asterisk following the description) can be turned off by the control word followed by 0 .

Highlighting

This property applies highlighting to text. The formatting is not a character format, so it cannot be part of a style definition.

For \highlight, the N argument can have the following values:

Special Characters

The RTF Specification includes control words for special characters (described as <spec> in the character-text syntax description). If a special-character control word is not recognized by the RTF reader, it is ignored, and the text following it is considered plain text. The RTF Specification is flexible enough to allow new special characters to be added for interchange with other software.

The special RTF characters are listed in the following table.

A carriage return (character value 13) or linefeed (character value 10) will be treated as a \par control if the character is preceded by a backslash. You must include the backslash; otherwise, RTF ignores the control word. (You may also want to insert a carriage-return/linefeed pair without backslashes at least every 255 characters for better text transmission over communication lines.)

A tab (character value 9) should be treated as a \tab control word. Not all RTF readers understand this; therefore, an RTF writer should always emit the control word for tabs.

The following are the code values for the special characters listed.

Document Variables

Document variables are definable and accessed through macros. The group has the following syntax.

Bookmarks

This destination may specify one of two control words: \*\bkmkstart, which indicates the start of the specified bookmark, and \*\bkmkend, which indicates the end of the specified bookmark.

Bookmarks have the following syntax:

A bookmark is shown in the following example:

\pard\plain \fs20 Kuhn believes that science, rather than 
discovering in experience certain structured 
relationships, actually creates (or already participates in) 
a presupposed structure to which it fits the data. 
{\bkmkstart paradigm} Kuhn calls such a presupposed 
structure a paradigm.{\bkmkend paradigm}

The bookmark start and the bookmark end are matched with the bookmark tag. In the example, the bookmark tag is "paradigm." Each bookmark start should have a matching bookmark end; however, the bookmark start and the bookmark end may be in any order.

\bkmkcolfN is used to denote the first column of a table covered by a bookmark. If it is not included, the first column is assumed. \bkmkcollN is used to denote the last column. If it is not used, the last column is assumed. These controls are used within the \*\bkmkstart destination following the \bkmkstart control. For example, {\*\bkmkstart\bkmkcolf2\bkmkcoll5 Table1} places the bookmark "Table1" on columns 2 through 5 of a table.

Pictures

An RTF file can include pictures created with other applications. These pictures can be in hexadecimal (the default) or binary format. Pictures are destinations, and begin with the \pict control word. The \pict keyword is preceded by \*\shppict destination control keyword as described in the following example. A picture destination has the following syntax:

These control words are described in the following table. Some measurements in this table are in twips; a twip is one-twentieth of a point.

Example:

{\*\shppict {\pict \emfblip ..... }}{\nonshppict {\pict ....}}

For more information on the GetDIBits and GetBitmapBits functions and the structure of Windows device-independent and device-dependent bitmaps, see Volume 1 and Volume 2 of the Programmer's Reference in the Microsoft Windows 3.1 Software Development Kit. For best device-independence and interoperability with Microsoft products, however, use of the \wbitmap and \dibitmap control words is discouraged. Rather, bitmaps should be embedded within Windows metafiles and the \wmetafile control word used. For more information on embedding bitmaps within metafiles, see Volume 1 and Volume 2 of the Programmer's Reference in the Microsoft Windows 3.1 Software Development Kit.

The \wbitmap control word is optional. If no other picture type is specified, the picture is assumed to be a Windows bitmap. If \wmetafile is specified, the N argument can be one of the following types.

For more information about these types, see volume 1 of the Programmer's Reference in the Microsoft Windows 3.1 Software Development Kit.

If \pmmetafile is specified, the N argument can be one of the following types.

For more information about these types, see volume 2 of the OS/2 Programmer's Reference.

Be careful with spaces following control words when dealing with pictures in binary format. When reading files, RTF considers the first space after a control word the delimiter and subsequent spaces part of the document text. Therefore, any extra spaces are attached to the picture, with unpredictable results.

RTF writers should not use the carriage-return/linefeed (CR/LF) combination to break up pictures in binary format. If they do, the CR/LF combination is treated as literal text and considered part of the picture data.

The picture in hexadecimal or binary format follows the picture-destination control words. The following example illustrates the destination format:

{\pict\wbitmap0\picw170\pich77\wbmbitspixel1\wbmplanes1\wbmwidthbytes22
\picwgoal505
\pichgoal221
\picscalex172
\picscaley172
49f2000000000273023d1101a030
3901000a000000000273023d98
0048000200000275
02040000200010275023e000000000
273023d000002b90002b90002
b90002b90002b9
0002b90002b90002b90002b90002b90002
b92222b90002b90002b90
002b90002b9
0002b90002b90002b90002b9000

Objects

Microsoft OLE links, Microsoft OLE embedded objects, and Macintosh Edition Manager subscriber objects are represented in RTF as objects. Objects are destinations that contain a data part and a result part. The data part is generally hidden to the application that produced the document. A separate application uses the data and supplies the appearance of the data. This appearance is the result part of the object.

The representation of objects in RTF is designed to allow RTF readers that don't understand objects or don't use a particular type of object to use the current result in place of the object. This allows the appearance of the object to be maintained through the conversion even though the object functionality is lost. Each object comes with optional information about the object, a required destination that contains the object data, and an optional result that contains the current appearance of the object. This result contains standard RTF. It is an important responsibility of the RTF writer to provide the result so that existing RTF readers that either do not support objects or that do not support the particular type of object will be able to display the object.

When the object is an OLE embedded or linked object, the data part of the object is the structure produced by the OLESaveToStream function. Some OLE clients rely on the OLE system to render the object and a copy of the result is not available to the RTF writer for that application. For these cases, the object result can be extracted from the structure produced by the OLESaveToStream function. For information about the OLESaveToStream function, see the Microsoft Object Linking and Embedding Software Development Kit.

The syntax for this destination is:

When Word is used as an editor for Mail, the following control word can be emitted. It is not seen in other situations.

Macintosh Edition Manager Publisher Objects

Word for the Macintosh writes publisher objects for the Macintosh Edition Manager in terms of bookmarks (see "Bookmarks" on page 41 of this Application Note). The range of publisher objects are marked as bookmarks, so these controls are all used within the \bkmkstart destination. The RTF syntax for a publisher object is:

Drawing Objects

Word 6.0/95 RTF

Drawing objects and the drawing primitives enumerated within drawing object groups use the syntax described by the following tables.

Note that in <dpgroup> the number of <dpinfo>s is equal to the argument of \dpcount, whereas in <dppolyline> the number of <dppt>s is equal to the argument of \dppolycount.

The following elements of the drawing-object syntax pertain specifically to callout objects:

The remaining elements of the drawing object syntax are properties applied to individual drawn primitives:

The following table describes the control words for the drawing object group in detail. All color values are RGB values between 0-255. All distances are in twips. All other values are as indicated.

The following values are available for specifying fill patterns in drawing objects with the \dpfillpat control word.

Word 97 RTF for Drawing Objects (Shapes)

Basic Format

The basic format for drawing objects in RTF is as follows

{ \shp   ........  { \*\shpinst  { \spp  { \sn .......... }  { \sp .............. }  }  }
            { \shprslt   ............... }   }

The first destination (\shp) is always present. This control word groups everything related to a shape together. Following the destination change, comes basic information regarding the shape. The following keywords with values can appear in any order after the "{ \shp" control word.

{ \shptxt  Any Valid RTF for the current textbox }

{ \shpgrp  ....... { \shp ..... (and all sub-items as usual) }
	           { \shp ......(and all sub-items as usual) }

With the exception of \shplid, these do not apply for shapes that are within a group. For more information about groups, see the "Introduction" section of this Applicaiton Note.

Drawing Object Properties

The { \shp ............ control word is followed by { \*\shpinst

The bulk of a shape is defined as a series of properties. Following the { \*\shpinst is a list of all the properties of a shape each in the following format:

{ \sp  { \sn PropertyName } { \sv PropertyValueInformation } }

The control word for the drawing object property is \sp. Each property has a pair of name (\sn) and value (\sv) control words placed in the shape property group. For example, the vertical flip property is represented as:

{\sp{\sn fFlipV}{\sv 1}}

Here, the name of the property is fFlipV and the value is 1, which indicates True. All shape properties follow this basic format. Only properties that have been explicitly set for a shape are written out in RTF format. Other properties assume the default values (a property may be set to the default value explicitly).

The following table describes all the names of properties for drawing objects along with the type of their corresponding value.

The format of the value depends on the property name it is paired with. Many values are simple single numbers. Distances are expressed in EMU units. There are 12700 EMU units in a point hence 914400 in an inch and 360000cm^-1. Fractional or fixed values are expressed using units that are 1/65536^th of a whole. Angles are expressed as fractions of a degree. Colors are 24 bit color values. Booleans have two possible values: 1 for True and 0 for False.

Arrays are formatted as a sequence of number separated by semicolons. The first number tells the size of each element in the array in bytes. The number of bytes per element may be 2, 4, or 8. When the size of the element is 8, each element is represented as a group of two numbers. The second number tells the number of elements in the array. For example, the points of a square polygon are written as:

{sv 8;4;{0,0};{100,0};{100,100};{0,100}}

The ShapeType property can have the following possible values.

The following keywords are related to defining a hyperlink hanging off of a shape (that is, all of them are inside of a {\sp {\sn ... } {\sp ...}}). These specifically can occur in the \sp to define a property that is a hyperlink. They are used like this:

{ \hl  { \hlloc  RTF-string } { \hlsrc RTF-string } { \hlfr RTF-string } }

The three groups can be in any order. These provide the three strings needed to describe a hyperlink fully.

Footnotes

The \footnote control word introduces a footnote. Footnotes are destinations in RTF. A footnote is anchored to the character that immediately precedes the footnote destination (that is, the footnote moves with the character to which it is anchored). If automatic footnote numbering is defined, the destination can be preceded by a footnote reference character, identified by the control word \chftn. No Microsoft product supports footnotes within headers, footers, or comments (annotations). Placing a footnote within headers, footers, or comments (annotations) will often result in a corrupted document.

Footnotes have the following syntax.

Here is an example of a destination containing footnotes:

\ftnbj\ftnrestart \sectd \linemod0\linex0\endnhere \pard\plain
\ri1170 \fs20 {\pu6 Mead's landmark study has been amply annotated.\chftn
{\footnote \pard\plain \s246 \fs20 {\up6\chftn }See Sahlins, Bateson, and 
Geertz for a complete bibliography.}
It was her work in America during the Second World War, however, that forms
the basis for the paper. As others have noted, \chftn
{\footnote \pard\plain \s246 \fs20 {\up6\chftn}
A complete bibliography will be found at the end of this chapter.}
this period was a turning point for Margaret Mead.}
\par

To indicate endnotes, the following combination is emitted: \footnote\ftnalt. Existing readers will ignore the \ftnalt control word and treat everything as a footnote.

For other control words relating to footnotes, see the sections titled "Document Formatting Properties" (page 16), "Section Formatting Properties" (page 20), and "Special Characters" (page 38) in this Application Note.

Comments (Annotations)

RTF comments (annotations) have two parts; the author ID (introduced by the control word \atnid) and the annotation text (introduced by the control word \annotation); there is no group enclosing both parts. No Microsoft product supports comments (annotations) within headers, footers, or footnotes. Placing an annotation within headers, footers, or footnotes will often result in a corrupted document. Each part of the annotation is an RTF destination. Comments (annotations) are anchored to the character that immediately precedes the annotation.

If an annotation is associated with an annotation bookmark, the following two destination control words precede and follow the bookmark. The alphanumeric string N, such as a long integer, represents the bookmark name.

Comments (annotations) have the following syntax:

An example of annotation text follows:

An example of a paradigm might be Newtonian physics or
Darwinian biology.{\v\fs16 {\atnid bz}\chatn{\*\annotation
\pard\plain \s224 \fs20 {\field{\fldinst page \\#'"Page: 
'#'\line'"}{\fldrslt}}{\fs16 \chatn }
How about some examples that deal with social science? 
That's what this paper is about.}}

Comments (annotations) may have optional time stamps (contained in the \atntime destination) or icons (contained in the \atnicn destination).

Fields

The \field control word introduces a field destination, which contains the text of fields. Fields have the following syntax:

There are several control words that alter the interpretation of the field. These control words are listed in the following table.

Two subdestinations are required within the \field destination. They must be enclosed in braces ({ }) and begin with the following control words.

If the instruction for a field contains a file name, then the \cpg control can be used to define the character set of the file name. See "Code Page Support" on page 9 of this Application Note for details.

The \fldrslt control word should be included even if no result has been calculated because most readers (even those readers that do not recognize fields) can generally include the value of the \fldrslt destination in the document. A field result should not start with a table, because this will break some RTF readers.

An example of some field text follows:

{\field {\*\fldinst AUTHOR \\*MERGEFORMAT	}{\fldrslt Joe Smith}}\par\pard
{\field{\*\fldinst time \\@ "h:mm AM/PM"}{\fldrslt 8:12 AM}}

You can use the \fldalt control word to specify that the given field reference is to an endnote. For example, the following field in RTF is a reference to a footnote

{\field{\*\fldinst NOTEREF _RefNumber } {\fldrslt 1}}

The following is an example of a reference to an endnote

{\field{\*\fldinst NOTEREF _RefNumber \fldalt } {\fldrslt I}}

If the specified field is a form field, the \*\datafield destination appears as a part of <char> and contains the binary data of a form field instruction. For example:

{\field{\*\fldinst {\*\bkmkstart Text1} FORMTEXT
 {{\*\datafield 
00000000000000000554657874310008476565207768697a0000000000000000000000}}}
{\fldrslt Default Result}}
{\*\bkmkend Text1}

Note that the \datafield destination requires the \* prefix. The \fldtype, \date, \time, and \wpeqn field keywords should be ignored.

Form Fields

Index Entries

The \xe control word introduces an index entry. Index entries in RTF are destinations. An index entry has the following syntax:

If the text of the index entry is not formatted as hidden text with the \v control word, the text is put into the document as well as into the index. For more information on the \v control word, see "Character Formatting Properties" on page 34 of this Application Note. Similarly, the text of the \txe subdestination, described later in this section, becomes part of the document if it is not formatted as hidden text.

The following control words may also be used.

Table of Contents Entries

The \tc control word introduces a table of contents entry, which can be used to build the actual table of contents. The \tcn control word marks a table of contents entry that will not have a page number associated with it; this is used in place of \tc for such entries. Table of contents entries are destinations, and they have the following syntax:

As with index entries, text that is not formatted as hidden with the \v character-formatting control word is put into the document. The following control words can also be used in this destination.

Bidirectional Language Support

RTF supports bidirectional writing orders for languages such as Arabic. The controls are described below (as well as in the appropriate sections throughout this Application Note). Also refer to the associated character properties defined in "Associated Character Properties" on page 37 of this Application Note.

All the control words relating to bidirectional language support are repeated here for convenience.