Joe is a systems programmer at a major hardware vendor. He is a graduate of Georgetown University and currently lives and works in the Washington, DC area. He can be contacted at jhlavaty@aol.com.
At some time or another, every Windows-application developer has to generate help files. However, the standard method of generating Windows help files is tedious and complicated, requiring nonintuitive commands that give little indication of the actual function they represent. For example, $\footnote creates a topic title.
Furthermore, the Windows 3.1 SDK help compiler (HC) requires a Rich Text Format (RTF) file format, locking you into using a word processor or text editor that supports the RTF specification. The 3.1 SDK does introduce an "extended subset" RTF spec, which means that you can write help topic files without an RTF-generating word processor, but this doesn't help you associate commands with function (for example, \uldb marks a "hot spot" in help text). You could use the RTF specification to discover these commands, if you did not have access to the Windows 3.1 SDK. However, you would only know through trial and error which tags are understood by the help compiler. (Interestingly, the Windows 95 "WordPad" applet generates RTF files, unlike the Windows 3.1 Write program.)
This process is further complicated by the fact that the resulting RTF file can only be understood by an expert in Windows help-file generation. Many of the Windows help specification's commands are buried in footnotes that are difficult to associate to the text they are generated from.
The RTFHelp filter I present here is an intuitive, readable process for easy Windows help-file generation. At the very least, it is more intuitive and readable than the usual process for Windows help-file generation. The RTFHelp filter takes a simple tagged file--created with any text editor--and generates an RTF file that can be passed through the Windows help compiler. The tagged file that RTFHelp processes can use any of the tags from the list in Table 1. Note, however, that certain help functions require specific tags in a particular order. This is a requirement of the Windows help specification, not RTFHelp. The RTFHelp executable and source code is available electronically; see "Availability," page 3.
RTFHelp is a bound executable. The version available electronically was developed with MSC 6.x using standard C libraries for OS/2. The resulting executable (a protected-mode OS/2 1.x character-based application) is run through the bind utility, which creates a DOS character-based version of the application in the same executable. The resulting executable is larger than normal, but runs as both an OS/2 application and a DOS application. Of course, if you do not have access to OS/2 libraries, you can build just the DOS version of RTFHelp by linking with a DOS C library. RTFHelp source, however, is completely operating-system independent and makes only C standard-library calls.
The RTFHelp process and the normal Windows process are shown in Table 2. RTFHelp does add a small (automated) step to Windows help-file generation, namely the compilation of a help description code (HDC) file into an RTF file for the help compiler. With the RTFHelp process, instead of requiring an expensive, hard-to-use Windows word processor, you can use any editor that can create ASCII text files. All you do is write your help text, tag it, run it through RTFHELP to generate a RTF file, and then pass the resulting file to the Windows help compiler to generate an HLP file for your Windows application.
The file SAMPLE.HDC in Listing One is the tagged file that is the source for the Windows Help file that accompanies this article (SAMPLE.HLP). All RTFHelp keywords must be typed in upper case, minimizing the potential for user-untagged help text to conflict unintentionally with RTFHelp keywords. Upper case also helps the keywords stand out in the source file.
I put initial values for margins and the like at the start of the HDC file. This help file begins with the DEFFONT 0 line, which selects the first font in the font table (which is zero-based) to be used as the default font for this help file. The font table is RTFHelp dependent. The FONTSIZE 24 means that your help file wants a 12-point (1/6") font to be our default font size. The LEFTINDENT 720 and RIGHTINDENT 720 lines give us 1/2" left and right margins in our help window. This means that no matter what the size of our help window, Windows will try to maintain one-half inch left and right empty margins surrounding our text within the help window. Note that the FONTSIZE command and the LEFTINDENT command use two different units: The FONTSIZE parameter is given in 1/2 points, and LEFTINDENT parameters are given in 1/20th of a point values. These are restrictions of the Rich Text Format specification itself. RTFHelp could be modified to give some standard measurement for many such commands, but this would require analysis and conversion of these units internally. RTFHelp does not currently do this; all values are simply passed straight through the filter to the generated RTF file. If you desire such a function, it's best to take TWIPs (the smallest unit of measure) as your standard unit for ease and reliability of conversions; see Table 3 for conversions.
Help files are broken down into topics, with each topic a collection of all information found on a single page. The first topic consists of all comments and text up to (and not including) the next PAGE tag that will begin a new page. The first topic is usually the table of contents of the help file. You can make another topic the contents by adding a CONTENTS=<context-string> statement to the [OPTIONS] section of your help project file. The <context-string> must be a literal value defined by a DEFINEPOPUP or DEFINELINK statement in your help file. If no CONTENTS string is given, then the first topic is assumed to be the table of contents.
The table of contents is often the first topic that the user sees, and it's used frequently. I like tables of contents to consist mostly of links and contain little raw text. The table of contents is quickly accessible by clicking on the Contents button while the help file is loaded, so this topic can be used to quickly locate a particular section of a help file, much as a book's table of contents might be used to isolate a search for information to a particular chapter. If finer granularity is needed, then the Search dialog can be used. The sample help file's table of contents is almost entirely hot spots: either descriptions of the source files making up RTFHelp or links to other topics within the help file.
Almost all topics contain a TITLE tag. The text in this title statement is visible to the user in the Search and History dialog boxes, so it should clearly distinguish this topic from all others in the help file. The TITLE text does not appear in the topic itself. For this topic, the multiword string: "The first topic is usually the TABLE OF CONTENTS for the help file" is the title. This command resolves to a $\footnote group in the generated RTF file.
Following the TITLE text, we find a KEYWORD tag. This tag can have multiple arguments, and the KEYWORD tag itself can occur more than once in the same topic. Keywords can be separated by semicolons and can include spaces. All keywords in the help file will be displayed to the user in the Search dialog; the user can then select one to isolate the search to one (or more) topics containing that keyword. The same keyword can be found in any number of topics. The more topics that contain a keyword, however, the less effective that keyword becomes. This tag resolves to a K\footnote group in the generated RTF file.
Next we find a BROWSESEQ tag. The parameter to a BROWSESEQ tag can be any string. Take care to keep all strings in all your BROWSESEQ tags of identical length and form, as WinHelp maintains the order of your tags by sorting the strings alphabetically. This tag resolves to a +\footnote group in the generated text file.
None of these commands have added any visual information to the topic as far as WinHelp is concerned. For tags that generate text in the topic window, let's first look at SA 90, which generates 1/16" of whitespace following the current paragraph. Then the following PARA tag ends the current paragraph. This is functionally equivalent to SB 90 without the PARA command. Use whichever you are more comfortable with.
At this point, I define a hot spot--a pop-up window with the text "rtfhmain.c" (given as the argument to the PUTPOPUP command). This command requires an XREFID (context string), which identifies the text to be displayed in the pop-up window. The POPUP command resolves to a \ul group, and the XREFID to a \v group in the generated RTF file. Note that we added a PARA tag to end the current paragraph here so that each of our pop-up window links would be on separate lines. This is simply a matter of style. You could code your own help files so as to have multiple links on the same line in your topic. Note also that I ended the last link with a PARA tag--otherwise the following paragraph of text would begin immediately after our last link, which is what we intended. I prefer to give a standard prefix (PTR_) to all of my pop-up window XREFIDs. This makes it easier for me to recognize them when scanning the file. You may use any prefix that you wish, or none at all.
Any line of text not beginning with a keyword is considered raw text, and is simply written out to the generated RTF file unprocessed by RTFHelp. This section of the topic contains a paragraph of instructions to the user, ended with a PARA command. Remember that this paragraph is using the margins and font selected earlier. As noted previously, many formatting properties are "inherited" from one formatting group to another so there is no need to change margins or font or other defaults. I do change the font size to an 8-point font with the FONTSIZE 16 statement.
Following the pop-up window hot spots and paragraph of instructions for the user, I add a number of jump hot spots. Notice that while both pop-up windows and jumps have a similar structure and form, their function is different. A popup may be viewed as an extension of the current topic (it adds something to it, such as defining a term used in the topic). A jump is more of a split from the current topic to a new topic, even though the two topics may be related in some way.
A jump is added to the text file with the PUTLINK command. The first jump is PUTLINK Margins and Spacing, where, as with PUTPOPUP, "Margins and Spacing" is the text to be displayed in the hot spot for the user. As PUTPOPUP, the PUTLINK command must immediately be followed by an XREFID tag (context string) that names the topic to be linked to (in this case, LINKTO_MARGINSANDSPACING). The PUTLINK command resolves to a \uldb group, and the XREFID, to a \v group in the generated RTF file. Again, you add a PARA tag to the end of every PUTLINK/XREFID pair so that each is displayed on an individual line. You could just as easily have put any number of these on a single line of text or in a single paragraph. For consistency, I begin all my links with the LINKTO_ prefix. You can use a different prefix (or none at all).
I explicitly end this topic with the PAGE command. Any text or commands following this PAGE command are considered to be in the next topic. Note that the first line of text is considered the start of a new paragraph, and thus the default SB distance will be skipped before displaying the text of the paragraph, as with any other paragraph. The PAGE command resolves to the \page control word in the generated RTF file.
The first new tag in this topic is DEFINELINK. Note that the LINKTO_MARGINSANDSPACING argument to this tag is the same string that appeared in an XREFID tag in the first topic. As you might expect, only one topic in any given help file can have a particular DEFINELINK string, otherwise the help compiler will not know which topic to resolve the link to when the user clicks on the hot spot to the jump. There may, however, be any number of XREFIDs that point to the same DEFINELINK, as this situation is not ambiguous. The DEFINELINK command resolves to a #\footnote string in the generated RTF file.
Another tag used in this topic is PARD, which sets the attributes of the current paragraph to the defaults, unless otherwise overridden within the paragraph. The paragraph will not inherit formatting from the previous paragraph. FIRSTINDENT sets a special indent for the first line of a paragraph. The FIRSTINDENT value is added to the LEFTINDENT value to get the actual horizontal offset. If FIRSTINDENT is 0, then the first line and all other lines of a paragraph will be positioned at the same horizontal offset. If FIRSTINDENT is positive, then the first line of a paragraph will be further from the left border than other lines. If FIRSTINDENT is negative, then the first line of a paragraph will be closer to the left border than the other lines of a paragraph. For example, to get a 1/2" left margin with the first line of a paragraph at the left border (0), use LEFTINDENT 720 and FIRSTINDENT --720. FIRSTINDENT, LEFTINDENT, and RIGHTINDENT resolve to the \fi, \li, and \ri control words respectively in the generated RTF file.
In the next topic you find even more text-formatting tags, such as BOLD, ITALIC, and SMALLCAPS. These tags are not inheritable. Their formatting property exists only for the text given as their argument. Note the use of the SPACECHAR character to force a space on lines after the first. This "hard space" is necessary because RTFHelp removes spaces found between a tag and its argument. Raw lines of text never require the use of the SPACECHAR character, as spaces will always be preserved. These commands resolve to the \b, \i, and \scaps groups, respectively, in the generated RTF file. The SPACECHAR character ensures that when the help compiler wraps the text (and it will, or it will remove the space), spacing will still be appropriate.
The next topic uses the BMC command to include a bitmap file in the help file at the current text position. If it is not found in the help directory, the bitmap should also be listed in the [BITMAPS] section of the help project file. Copy pyramid.bmp from your Windows 3.1 directory or add any other bitmap to build a bitmap into your help file. Alternatively, comment out this bmc command in the hdc file.
The BOX tag is used to draw a single-line border around the current paragraph. The BOX attribute is inheritable. If you do not want all other paragraphs following this one to also be boxed, then you should reset the following paragraph to the defaults with the PARD command. This tag resolves to the \box control word in the generated RTF file.
RTFHelp also has support for tab characters and tab stops. You can use the DEFTAB command to set the tab stops every so many units. For example, DEFTAB 2880 gives you tab stops every two inches. To tab, simply insert the TAB tag in your text. These commands resolve to the \deftab and \tab control words, respectively, in the generated RTF file.
Lastly, you encounter the DEFINEPOPUP tag. I put all of my DEFINEPOPUPS last in my file as the help compiler requires each topic to have only one DEFINEPOPUP tag. Because of this, RTFHelp must generate a \page tag for each one. The generated RTF text for the DEFINEPOPUP tag is \page #\footnote <context string>. The DEFINEPOPUP tag is followed by any amount of text, which will be the information displayed in the pop-up window when the user selects the hot spot for this popup. The context string, of course, must have been referenced by an XREFID elsewhere in the file in order for it to be potentially visible to the user.
A project file is conceptually a makefile for help compilation. The help compiler uses it to find out what files to process and what options to use during the compilation. A project file is made up of sections, each of which has a name in brackets. The only required section of the HPJ file is the [FILES] section, which lists the topic files to be compiled.
The [OPTIONS] section keywords control the generation of a help file. The [OPTIONS] section should be the first section in your help project file to ensure that all options will apply to the full help-compiler build. The TITLE keyword sets the title-bar text when the .HLP file is loaded into WinHelp to that given by the author as the value of the TITLE keyword. The COPYRIGHT keyword adds a user copyright notice to the help file displayed when the user selects Help, About from WinHelp. One option not used by RTFHelp's sample file is the CONTENTS keyword. This keyword specifies a context string (see DEFINELINK) that will be the Contents topic (table of contents) for this help file.
The [FILES] section lists the topic files to be input to the help compiler. Each file is listed on a separate line.
The [BITMAP] section lists the bitmap files to be used in the help file. These file names should be fully qualified if they are not in the same directory as the topic files that reference them.
The [CONFIG] section can contain a number of help macros. Example 1 uses the BrowseButtons() macro to enable browse buttons in WinHelp for our help file.
For more information on the RTF commands, refer to the Rich Text Format (RTF) Specification, Version 1.3, available from Microsoft product-support services and numerous other online services.
Command Function
BMC Inserts a bitmap file in your help file.
BOLD Text following the tag is displayed in bold.
BOX Puts a boxed border around the current paragraph.
BROWSESEQ Assigns a browse sequence number to a topic.
CENTER Ends a paragraph and aligns it centered within the margins.
DEFFONT Sets a new default font from the font table.
DEFINELINK Marks a topic that is the target of a link.
DEFINEPOPUP Defines the content of the popup.
DEFTAB Assigns a new default tab width.
FIRSTINDENT Defines the offset of the first line of a paragraph.
FONT Sets current font to a new font.
FONTSIZE Sets size of the current font to a new size.
ITALIC Displays text following the tag in italic.
JUST Ends paragraph and justifies the text in it.
KEEP Keeps the lines of this paragraph together (no wrap).
KEEPNEXT Creates a nonscrollable region at the top of this topic.
KEYWORD Defines a keyword (found during a search in the SEARCH box).
LEFT Ends current paragraph and aligns paragraph to the left.
LEFTINDENT Defines the offset of the left margin of a paragraph.
LINE Begins new line within the current paragraph.
PAGE Starts new page, and, hence, a new topic in the help file.
PARA Ends paragraph.
PARD Assigns default settings to the paragraph and ends same.
PLAIN Resets paragraph formatting to plain settings.
PUTLINK Marks hot spot to link.
PUTPOPUP Marks hot spot to pop-up window.
RIGHT Aligns paragraph to the right.
RIGHTINDENT Defines the offset of the right margin of a paragraph.
SA Space after, places vertical whitespace after a paragraph.
SB Space before, places vertical whitespace before a paragraph.
SL Space between, places vertical whitespace between
lines of a paragraph.
SMALLCAPS Text following tag is displayed in small caps.
SPACECHAR Assigns new character to be used as a hard space.
TAB Inserts TAB character.
TITLE Sets title for this topic (found during a search in the GOTO box).
TX Sets position of tab stop, defaults to every 1/2" if not set.
TQC Tab center, advances to the next tab stop and centers text.
TQR Tab right, advances to the next tab stop and aligns text right.
XREFID ID of the term (UPPERCASE_LETTER).
* Begin comment (in column 1).
; Equivalent to "*", a comment.
(a) 1. Edit file using full-featured word processor and WinHelp specification commands. Save file in RTF format. 2. Run RTF output (first pass) through the Windows help compiler (HC) to generate a help file. 3. Launch WinHelp and verify the generated .HLP file. (b) 1. Edit file in any editor or word processor that supports ASCII using RTFHelp keywords. Save file as ASCII text. 2. Run output of first pass through RTFHelp to generate an RTF file. 3. Run RTF output (second pass) through the Windows help compiler to generate a help file. 4. Launch WinHelp and verify the generated .HLP file.
Points 1/2 points TWIPs Inches
144 288 2880 2
72 144 1440 1
54 108 1080 3/4
36 72 720 1/2
24 48 480 1/3
18 36 360 1/4
12 24 240 1/6
9 18 180 1/8
4.5 9 90 1/16
; J. Hlavaty, 1994 [OPTIONS] TITLE = RTFHelp Sample Help File COPYRIGHT = Help file content copyright (C) J. Hlavaty, 1994 [FILES] sample.rtf [BITMAPS] pyramid.bmp [CONFIG] BrowseButtons()
* J. Hlavaty, RTFHelp sample file
* defaults for the file go here
DEFFONT 0
FONTSIZE 24
* Justified text, with a 1/2" left and 1/2" right margin (1440 twips/inch)
LEFTINDENT 720
RIGHTINDENT 720
* Now begin the first topic
* The TITLE tag introduces a topic (page) of a help file.
TITLE The first topic is usually the TABLE OF CONTENTS for the help file
* The following statements select 12 point TmsRmn out of RTFHelp's default
* font table. What we'll actually get depends on the available fonts
* in the session of Windows in which the help file is executing.
* As noted in the text, measurements for tags like LEFTINDENT are in TWIPs
* (an abbreviation for twentieths of a point). To convert inches to twips,
* simply multiple inches by 1440 (72 points in an inch times twenty).
* Other tags, like FONTSIZE are in 1/2 points so FONTSIZE 72 is 36 point
* (meaning 1/2") type. Note that LEFTINDENT (twips) tag arguments are
* ten times the equivalent FONTSIZE argument
KEYWORD Table of Contents
* note that if you wish your pop-up topics or links to be each on
* an individual line, then you must use PARA tags to force the separation.
* Don't forget the last PARA tag, or the text following these definitions
* will begin on the same line as the last one
BROWSESEQ rtfhelp:005
* Add 1\16th" (90 twips) of whitespace after each of the following
* definitions for readability
SA 90
PARA
PUTPOPUP rtfhbann.c
XREFID PTR_RTFHBANN_C
PARA
PUTPOPUP rtfhcp85.c
XREFID PTR_RTFHCP85_C
PARA
PUTPOPUP rtfhdata.c
XREFID PTR_RTFHDATA_C
PARA
PUTPOPUP rtfhhelp.c
XREFID PTR_RTFHHELP_C
PUTPOPUP rtfhmain.c
XREFID PTR_RTFHMAIN_C
PARA
PUTPOPUP rtfhpars.c
XREFID PTR_RTFHPARS_C
* Without the following PARA, this text would be right next to RTFHHELP.C
* PUTPOPUP
* Switch to a smaller font
FONTSIZE 16
PARA
Please select one of the terms above by single-clicking on it with the left
mouse button to view its definition, or go to a topic below by clicking on it.
PARA
FONTSIZE 24
* The PUTLINK tag tells the user where the link will go
PUTLINK Margins and spacing
* The XREFID tag must also be used to tell the help compiler what DEFINELINK
* to go to
XREFID LINKTO_MARGINSANDSPACING
PARA
PUTLINK Special Effects
XREFID LINKTO_SPECIALEFFECTS
PARA
PUTLINK Bitmaps and graphics
XREFID LINKTO_BITMAPSANDGRAPHICS
PARA
PUTLINK WinHelp Terms
XREFID LINKTO_WINHELPTERMS
PARA
PUTLINK RTFHelp Terms
XREFID LINKTO_RTFHELPTERMS
* Now explicitly start a new topic (PAGE) with the PAGE tag, which has no
* arguments. The PAGE tag ends the current page.
* The help compiler will not like an extra \page tag on the first
* page. It will assume that the blank page is the table of contents
* if you do not have a CONTENTS tag in your HPJ file
PAGE
TITLE Text formatting in a help file
KEYWORD text formatting; left indent; right indent; hanging indent;
default paragraph settings
BROWSESEQ rtfhelp:010
DEFINELINK LINKTO_MARGINSANDSPACING
* now reset the spacing after each PARA to the default
* 90= 1/16th inch glue following each PARA
SA 90
JUST
LEFTINDENT 0
RIGHTINDENT 2880
This is text with a two inch right margin. This is just done for some contrast
with the paragraph below.
PARA
* Produces a "hanging" indent for the first line only. Note negative offset
* The actual value used for the first line's offset is LEFTINDENT+FIRSTINDENT
FIRSTINDENT -720
LEFTINDENT 720
RIGHTINDENT 720
this is text with a "hanging" indent, as you'll see the rest (lines after
the first) of this paragraph is indented normally.
PARA
SA 720
* Reset the firstindent/leftindent values to the default (720 ? )
FIRSTINDENT
LEFTINDENT
This paragraph has 1\2" "glue" (empty space) following. Notice that
the indent of the first and second lines are identical.
PARA
SA 0
This paragraph has no glue following
PARA
PARD
This is a paragraph using default paragraph settings
PARA
PAGE
TITLE Text formatting in a help file, continued
KEYWORD text formatting; italic; smallcaps; bold
BROWSESEQ rtfhelp:015
DEFINELINK LINKTO_SPECIALEFFECTS
* now reset the spacing after each PARA to the default
SA
LEFTINDENT 720
RIGHTINDENT 720
ITALIC This is italic text with half-inch left and right margins. Should
ITALIC %also appear as Justified Text if JUST tag is supported by the HC.
* JUST
PARA
LEFTINDENT 2880
RIGHTINDENT 0
* note that RTFHelp considers the end of a line to end certain tags. This is
* intentional so that certain formatting properties (bold, italic and so
* forth do not span lines)
JUST
LEFTINDENT 1440
SMALLCAPS This is text with a one inch left margin in small caps.
* Note the use of the hard space character (%) to force a space.
SMALLCAPS %flexibility that you can put in your help file.
PARA
* Reset leftindent to default
LEFTINDENT
BOLD This text is displayed in bold type.
BOLD %text (similar to underlining). Underlining is not supported by
BOLD %RTFHelp as the HC gives a specific meaning to the RTF underline
BOLD %command in help files.
PARA
PAGE
TITLE Bitmaps and graphics
KEYWORD bitmap; graphics
BROWSESEQ rtfhelp:020
DEFINELINK LINKTO_BITMAPSANDGRAPHICS
*
* You will need to copy pyramid.bmp from your \windows directory to the
* directory containing your HDC file for the bitmap to be found
*
BMC pyramid.bmp
This is a sample bitmap caption
SA 180
* begin a new paragraph and draw a box around it
PARA
BOX
DEFTAB 2880
TAB
1
TAB
This is one
LINE
TAB
2
TAB
This is two
PARA
PARD
PAGE
TITLE WinHelp Terminology
BROWSESEQ rtfhelp:025
* note that a ; separates multiple keywords (as multiword keywords are
* permitted) you can also have multiple KEYWORDs in the same topic
KEYWORD WinHelp terminology
KEYWORD topic file; topic; title; link; pop-up topic
DEFINELINK LINKTO_WINHELPTERMS
SA 90
The document containing the Rich Text Format (hereafter abbreviated RTF) text
input to the help compiler will be called the TOPIC FILE. One or more topic
files are used to generate a help file (a binary file with the .HLP
extension). Every topic file is made up of a series of "pages" or "screens"
of related information known as TOPICS.
PARA
Each topic can contain a variety of constructs, such as titles,
links and pop-up topics. A TITLE is not visible in the topic itself, but is
used in the Search and other WinHelp dialog boxes to allow the user to
distinguish this topic from others in the help file.
PARA
A LINK hooks one topic
to another so that when the user clicks on the link's hot spot, the topic
that the link references will become the current topic displayed to the user.
PARA
Finally, a POP-UP TOPIC when clicked on will create a child window on top of
the help window which contains information for the user. These pop-up topics
are often used for definitions of terms.
PAGE
TITLE RTF Terminology
BROWSESEQ rtfhelp:030
* note that a ; separates multiple keywords (as multiword keywords are
* permitted) you can also have multiple KEYWORDs in the same topic
KEYWORD RTFHelp terminology
KEYWORD control words; control symbols; groups
DEFINELINK LINKTO_RTFHELPTERMS
The topic file is a collection of RTF tags and raw text. These tags
are known as CONTROL WORDS and all contain a backslash as their first
character and consist of entirely lower case letters (RTF is case-sensitive).
One such tag is \\par to end a paragraph.
PARA
There is a small set of non-alphabetic control words known as CONTROL
SYMBOLS, such as \\~ which signifies a hard (non-breaking) space.
PARA
Control words and control symbols together with the text making up the
topic file are collected in GROUPS. A group begins with an open curly brace
and continues until an equally-nested closing curly brace. Any formatting
properties that are found within a group apply to all and only elements of
that group. Some groups can even inherit specific formatting properties from
the group preceding them. For details on exactly when and how this occurs,
refer to the RTF specification listed in the reference section.
PARA
RTFHelp uses the tagged file passed in by the user to generate an
RTF topic file containing a mixture of control words, control symbols and
groups.
PAGE
* Here are the definitions for our (what's the term) definitions
* A few warnings are in order. The DEFINEPOPUP generates a new page, so I
* generally put my DEFINEPOPUPs at the end of my help file.
* Note that the context ID (such as PTR_RTFHMAIN_C below) cannot have any
* text following it. This is because RTF assumes that any text following
* the context ID is actually a part of the context ID and includes it in
* the #{\footnote} tag that it builds. The help compiler will complain
* about this mixture of text and context ID. Because of this, there is a
* a restriction that text that is the definition of a DEFINEPOPUP must begin
* on the line following the DEFINEPOPUP tag and ID
DEFINEPOPUP PTR_RTFHMAIN_C
RTFHMain.c is the main module for RTFHelp. It reads the tagged input file,
and writes the formatted RTF text to the output file.
DEFINEPOPUP PTR_RTFHCP85_C
RTFHCP85.c is the module containing the translation table from CP850
(the so-called Latin 1 code page). This code page roughly corresponds to those
characters needed to display Western European languages. It converts to the
Windows default (ANSI) code page.
DEFINEPOPUP PTR_RTFHDATA_C
RTFHData.c is the module containing global data.
DEFINEPOPUP PTR_RTFHBANN_C
RTFHBann.c is the module containing the banner (logo) information
that is displayed when using the RTFHelp compiler.
DEFINEPOPUP PTR_RTFHHELP_C
RTFHHelp is the module that processes RTFHelp's command line arguments.
Named because it also displays help for the user.
DEFINEPOPUP PTR_RTFHPARS_C
RTFHHelp is the module that contains the RTFHelp parser.
Copyright © 1995, Dr. Dobb's Journal