Copyright © 2001-2022 Woodgrove Digital Engineering P⁄L. All rights reserved. Last revised:14th December 2022 CREDITS LINKS
Home Entertainment



Woodgrove Digital Engineering






MOVEMENT CONTROLLER

          This version incorporates all changes up to Change 386
                                                  Date 04-SEP-18


WP (WORD PROCESSOR) MANUAL



                     Copyright 1984-2018

             WOODGROVE DIGITAL ENGINEERING PTY. LTD.
          Australian Business Number (ABN) 44002794452

                      All rights reserved.

Contents

+

Prologue

 

    Using this Document

+

    Introduction

 

        Software

 

    Getting Started

+

The Word Processor

 

    Execution

 

    Input Files

 

    Output Files

+

    Writing the Input Files

 

        Paragraphing

+

        Word-Processing Instructions

 

            Title Page

 

            Page Title and Page Numbering

 

            Partitioning Your Document

 

            Context Sensitive Help

 

            Cross-references and Hyper-Text

 

            Points or Bullets

 

            Text Substitution

 

            Conditional Compilation

 

            Text Presentation Options

 

            Placing Text Explicitly

 

            Presentation of Text Screens

 

            Presentation of Pictures

 

            Page Formatting

 

            Customising for Your Printer

 

    Creating a Printout and the Help System

+

    Creating the HTML Document

 

        Required Contents of the Style Sheet File

 

    Creating a Rich Text Format File

 

    Using the Version and Change Log Files

Prologue

This document is the "Word Processor Manual" for the "Movement Controller".

This section includes the three introductory sections, "Using this Document", "Introduction" and "Getting Started".

The "Using this Document" section gives an overview of each section of the document.

The "Introduction" section gives a brief overview of the software components.

The "Getting Started" section documents the basic software configuration.

Using this Document

This section gives an overview of each section of the document.

This document is divided into the following major sections:

  • Prologue
  • The Word Processor

The "Prologue" section includes the three introductory sections, "Using this Document", "Introduction" and "Getting Started".  The "Using this Document" section (this section) gives an overview of each section of the document.  The "Introduction" section gives a brief overview of the system's function and its software components.  The "Getting Started" section documents the basic software configuration.

The "The Word Processor" section describes how to use the word processor to create the site-specific printed manuals, the Movement Controller help system, the HTML presentable, and the Rich-Text-Format versions of the manuals from the two single source documents.

In the printed document, cross-section references are made using the section and subsection numbers, separated by dots, followed by the final subsection name, and the entire string enclosed in double quotation marks.  When presented via the Movement Controller's help system, cross-section references are made using the final subsection name, enclosed in double quotation marks and highlighted as a hyper-text link.  When presented via an HTML rendering program, cross-section references are made using the final subsection name rendered as a hyper-text link.  For example, this section would be referred to as the section titled: "Using this Document".

Introduction

This manual describes how to use the Movement Controller's word processor to create, from common source documents:

  • the site-specific printed manuals for a software package,
  • the help system for a "C" language based software package,
  • the HTML presentable versions of the site-specific manuals, and
  • the Rich-Text-Format versions of the site-specific manuals.

This word processor was specifically developed to produce site-specific versions of the Movement Controller's OPERATOR'S MANUAL, TECHNICAL MANUAL, and SOFTWARE MANUAL from a single set of source-document files.

The software is designed to run on an IBM-compatible Personal Computer, running the Linux/X-Windows, Microsoft Windows, or MS_DOS operating system.  The computer's hardware requirements are minimal by today's standards.

Software

The following information outlines the purpose for each of the files comprising the Movement Controller's word processor.

The software consists of the following files:

  • The executable file, "wp", which is the word processor itself.
  • The HTML style sheet "Woodgrove.css", which is referenced by any output files generated for HTML rendering.

There is also the source document file "technica.wpi" which is this document. This document is suitable for processing by the word processor, and it is likely that you are currently viewing a file processed from this source document by this word processor.  This source document file is also the source document file for the Movement Controller's TECHNICAL MANUAL.

Associated with the "technica.wpi" file is a header file, "wp.wph" which customises the document to produce the specific manual which describes the word processor as a separate entity.  Batch or script files, "wp.bat", "html_wp.bat", and "rtf_wp.bat" are provided to call up the word processor with appropriate parameters to process these files to create the various versions of these documents.

The file, "technica.wpi", is to be word processed to create the "wp.all", "wp.odd", "wp.evn", and "wp.nve" files.  These files may be copied to a suitable printer.  The "wp.all" files contain all pages of the manual, whilst the "wp.odd" files contain only the odd pages and the "wp.evn" and "wp.nve" files contain only the even pages (with the pages presented in the reverse order in the "wp.nve" file).  The "wp.odd", and either the "wp.evn" or the "wp.nve", files may be used to facilitate double sided printing.

A suitable printer is a Hewlett Packard DeskJet 670C.  Though, probably, any HP laser or ink-jet printer and a host of similar printers from other manufacturers would be suitable.  The printer controls are listed in the file "deskjet.pcl".  Should you wish to support an alternate printer, make a copy of this file under a suitable name, and adjust the escape sequences appropriately, then modify the batch file "wp.bat" to reference this new file in place of "deskjet.pcl".

The file, "technica.wpi", may also be word processed to create the "wp.htm" file.  This may be read using an HTML rendering program, such as Microsoft Internet Explorer.  Alongside the HTML version of the file, will be produced a PHP version, that contains the HTML version, with PHP code to enable it to be compressed for delivery over the Internet.

The file, "technica.wpi", may also be word processed to create the Rich-Text-Format (RTF) of the file for presentation and printing by many standard word processors, such as Microsoft Word.  This file should not be edited, as it is generated from the ".wpi" file, so any edits would be lost when the file is next generated.

Getting Started

This section deals with the installation of word processor software.

The software consists of executable file, "wp" and the sample HTML style sheet file "Woodgrove.css".

Either a directory should be created for these files, and that directory should be included in the "PATH" environment variable, or else these files should be copied to an existing directory referenced by the "PATH" environment variable.

You may also wish to include in this directory, or a sub-directory of it, the remaining files from the distribution, namely: "technica.wpi", "wp.wph", "wp.all", "wp.odd", "wp.evn", "wp.nve", "deskjet.pcl", "wp.bat", and "html_wp.bat".

The Word Processor

The OPERATOR'S MANUAL, the TECHNICAL MANUAL, the SOFTWARE MANUAL, and the WORD PROCESSOR MANUAL, are each prepared in a specific language which is subsequently "compiled" to present the final forms of the documents for your site.  These "forms" are:

  • A number of files, in printer specific formats, which can be copied to the corresponding printers to produce either single-sided or double-sided printed documents.
  • The on-line help system for the Movement Controller's operator interface.
  • An HTML document which can be perused via an HTML reader, such as Microsoft's Internet Explorer or Firefox or Chrome or Safari.
  • A PHP document, which includes the HTML document, with a little PHP code at the start and end to allow it to be compressed for delivery over the Internet.
  • An RTF (Rich Text Format) file which can be printed using any of a number of popular word processing programs, such as Microsoft Word.  You should not attempt to edit this document.

The compiling is performed using the executable word-processing program, "wp". This is not a word-processor in the sense that "Word" and "WordPerfect" are, as it does not provide any editing functions.

The editing functions can, instead, be performed using any text-editor, or modern word-processor in non-document mode, providing they continue to support this mode.

The rendering is performed by either copying the files, intended for printing, to the printer, or using the help system of the Movement Controller, or viewing the HTML files using a third-party's HTML rendering program (commonly called a "browser"), or printing the RTF file using a third-party's word processor.

Hence, this product is not WYSIWYG (what-you-see-is-what-you-get).  Such products have the drawback that you don't know what you are going to get, unless you see the entire document, typically needing to check it before submitting each revision for printing.  Instead this product is designed to be WYAFIWYG (what-you-asked-for-is-what-you-get).  In this way, changes to one part of the document will not impact on another part.

This product is also designed to enable the production of several different documents, each with their own site-specific information, and chapters, from a single source document.

Execution

The word processor is executed from the command-line interpreter.  You would normally arrange for the path to the word processor (wp.exe) to be included in the PATH environment variable.  Then you need to type "wp" followed by the arguments.

The format of the command is as follows:


wp [-phtml | -prtf | -i<function_inc_filename>]  [-o<output_filename>]
   <header_filenames> <source_filenames>

There are four switches that may be specified, of which the first three are mutually exclusive:

  • -phtml
    This requests that the output is an HTML file.  A PHP file will also be produced to allow an HTTP server to deliver it in compressed form over the Internet.
  • -prtf 
    This requests that the output is an RTF file.
  • -i    
    This requests that, as well as producing an output in a form that can be sent directly to a printer, an index file is to be produced that will allow the Movement Controller's online help to present the manual.
  • -o    
    This must be immediately followed by the output filename without an extension, and specifies that this filename is to be used as the base for creating the required set of output files.

If neither of the first two switches (neither "-phtml" nor "-prtf") are specified, then the output that is produced will be in a form that can be sent directly to a printer.

After the switches (or scattered among them, if you like), you need to list the source files in the order in which you wish them processed.  The earlier source files would be header-type files, containing no text that will be sent to the output files, but instructions to the word processor.  Many of those instructions are expected to be the specifications of text substitutions, so they need to be processed before the main source document, which would reference those substitutions, is processed.  It is important that the main source document is the first that sports the extension, ".wpi".  This identifies it as the main source document, and it is this file's name that is used as the default file name for the output files.

The Movement Controller's online help needs, for the:

  • OPERATOR'S MANUAL,
    "operator.wph" and "operator.ndx", for the
  • TECHNICAL MANUAL, 
    "technica.wph" and "technica.ndx", and for the
  • SOFTWARE MANUAL,  
    "software.wph" and "software.ndx".

So if generating an index file to allow the Movement Controller's online help to present these manuals, then you must provide the corresponding header files ("operator.wph", "technica.wph", and "software.wph") and use the filename stems, "operator", "technica", and "software" for the main source documents, since it is from these that the ".ndx" file's name is based.

Input Files

The word-processor is designed to use a number of input files.  These are likely to include:

  • A "printer driver" or printer configuration file; a file which provides information for the word processor to let it know how to initialise the printer and what are the escape sequences it requires to set the "bold", "compress", and "italic" modes.
  • A header file, which will, typically contain definitions used to configure the main source document for a given site.
  • The main source document itself, which contains all the text required for all sites, with conditional compilation instructions, which test the definitions set in the header file, to omit sections of the document which are not relevant to a specific site.

All the above files share the same syntax, however certain instructions are best only located within specific files.  As the instructions are described below, those which would be expected to be included in the printer configuration file or the header file will be so indicated.

The header and printer configuration files should be listed first.  The main source document, itself, should be the first sporting the extension, ".wpi", as this will identify it as the main source document so that its filename will be used as the basis to set the output filenames.

Normally there would be a single printer configuration file, system-wide, for each printer supported, there would be a single source document for each software package, and there would be a single header file for each site.  It is expected that there would be a directory dedicated to each site.  Therefore, there might be one printer configuration file, which exists in a directory dedicated to printers (possibly a sub-directory of the directory dedicated to this word processor), a single source document, in a directory dedicated to the software package as a whole, and several header files, one corresponding to each site using the software package, each in different directories - those directories dedicated to the corresponding sites.

When producing the HTML document, a style sheet file, named "Woodgrove.css", must also be created, independently of the word-processor, to instruct the HTML rendering program how to present the document.  The format of this file is described in the HTML standards, however the requirements for this document are described below, in the section titled: "Required Contents of the Style Sheet File".

Output Files

The first output file you should be interested in is the log of error messages from the compilation of the input files.  This file is the standard error output file, which if not redirected, results in the errors being presented to the screen of the terminal from which it is run.  You would normally wish to redirect the standard error output to a file so that you can examine the errors at your leisure, using a text-editor.

If there are errors resulting from the compilation, there will be corresponding lines such as:


technica.wpi:1637:ERROR pagetitle within title page

The format of the error messages is the same as those produced by the Gnome "C" language compiler, "gcc", so, if you redirect the errors to a file, say "wp.err", you may use the text editor, "vim", with the command "vim -q wp.err" to edit the files containing the errors, presenting the offending lines on request.  If you intend to use this feature, please refer to the "vim" documentation.  The Microsoft "C" compiler also uses an error format that, although different to "gcc", is compatible with this feature of "vim".

Also, if there are any error messages produced, the return code produced by the word processor will be non-zero, so that errors may be trapped by "make". Also, if there are errors, the output files will be deleted to ensure that the next "make" operation will again attempt to generate the files.

The files produced for printing are:

  • The single-sided document, with the filename taken from the source document filename, minus the extension, with ".all" appended to it.
  • The odd pages for double-sided document, with the filename taken from the source document filename, minus the extension, with ".odd" appended to it.
  • The even pages for double-sided document in normal sequence, with the filename taken from the source document filename, minus the extension, with ".evn" appended to it.
  • The even pages for double-sided document in reverse sequence, with the filename taken from the source document filename, minus the extension, with ".nve" appended to it.

The file produced for the Movement Controller help system, is the index file, with the filename taken from the main source filename, minus any path information and its extension, with ".ndx" appended to it.  The Movement Controller uses this file, in conjunction with the main source document itself, to present the help pages.

The file produced for the HTML rendering program is the HTML document, with the filename taken from the main source filename, minus any path information and its extension, with ".htm" appended to it.  This file references the file "Woodgrove.css", as a style sheet.  The accompanying PHP file will use the extension ".php".

The file produced for input to a third-party's word processor has its filename taken from the source document filename, minus the extension, with ".rtf" appended to it.  It is only intended that the third-party's word processor is used to read or print the document, not to edit it, as any edits would be overwritten the next time the word processor is run.

Additionally, several temporary files are produced during the compilation.  These files are "WORKFILE.TMP", "CONTENTS.TMP", and "REFERENC.TMP".  These files are left in existence at the end of compilation, but their contents are reduced to zero.

Writing the Input Files

The input files are created using a text-editor, or modern word-processor in non-document mode, providing it supports this mode.

The bulk of each input file consists of printable ASCII text.  Each line of text is to be terminated with a carriage-return character (13 decimal, 0x0D hexadecimal, 015 octal), followed by a line-feed character (10 decimal, 0x0A hexadecimal, 012 octal).  These are non printing characters, which merely inform the program displaying the text (typically your text-editor) where the end of the line is.

This method of line termination is commonly known, in the IBM-PC world, as the DOS file format, so if you are using a Microsoft operating system, you should not concern yourself.  If you are using Unix, or Linux, should will need to instruct your editor to produce a DOS file, as it would otherwise not include the carriage-return character.

Paragraphing

The end of a paragraph is indicated by a blank line.  Unless the "Literal" instruction is in effect, all lines of text, without intervening blank lines, are treated as if presented on a single line, then broken down, by the word-processor into the lines of a paragraph, depending on the line length.

As a result, it makes no difference to the processed document, how many words you include on a line, only whether there are any there at all.  Similarly, it makes no difference how many spaces you place between words.

To arrange for text to be positioned explicitly, please refer to the section titled: "Placing Text Explicitly".

In rendering the document for printing, paragraphs are not split by page breaks. Also a section heading is similarly bound to its first paragraph, so a section heading will never appear as the last line of a page.

Word-Processing Instructions

In addition to the text, your input files will contain instructions to the word processor.  These instructions must be distinguished from the bulk of the text using either a single character which is guaranteed not to turn up in regular text, or a character sequence which is unlikely to turn up in regular text.  Traditionally, the escape character is used for this purpose, and it has been chosen for this purpose here.

The escape character (27 decimal, 0x1B hexadecimal, 033 octal) introduces the instruction to the word processor.  The remainder of the instruction is composed of printable ASCII characters. Once the word processor recognises the instruction, it uses its knowledge of the instruction's syntax to determine where the instruction finishes and the regular text continues.

In many text-editors, especially single mode screen editors, an escape character can be inserted by typing the [ESCAPE] key.  In dual mode (command mode and screen mode) text-editors, the [ESCAPE] key will typically be used to return you to command mode, whereas in command mode only text-editors, the [ESCAPE] key will typically be used to punctuate or terminate a command.  For such editors, you should refer to the editor's documentation to find out how to insert the escape character.  In the case of "VIM - Vi IMproved", a character can be inserted by entering screen mode (insert mode) and typing [CONTROL V] followed by the three character decimal representation of the escape character, "027".

In any examples given in this section, the escape character will be represented by the pair of printable ASCII characters, "^[", which is a common representation for control left-square-bracket, which in turn is a keyboard method of generating the escape code without using the [ESCAPE] key.  Examples are italicised and indented.

This document does not present as many examples as it might, since the source document, for what you are currently reading, contains examples of most of the instructions.

Title Page

Typically you will require a title page.  This is a single page, not included in the page numbering, and treated as page 0 for double sided printing purposes - hence it is an even page.

The definition of the title page should be included near the top of the source document, before any regular text.  It would typically be preceded by other word-processing instructions to, say, set the page formatting.

The definition commences with the string "^[titlepage".  There should be no other text on this line; any text found here will be ignored.

All text entered for the title page will be rendered where it is placed.  In other words, the literal mode is automatically engaged.

Typically you would include a title for the document, a version number, a revision date, the site identification, your company details, and so forth on this page.  Some of this information may be referenced symbolically, by calling up macros defined in the header file, especially for the site identification, and possibly also for the version number and revision date.  Please refer to the section titled: "Text Substitution".

You might also want to make use of the text presentation instructions.  Please refer to the section titled: "Text Presentation Options".

The end of the title page is identified by the string "^[end_titlepage".  Again there should be nothing else on this line.

Page Title and Page Numbering

Typically you will require a title for the top of each page.  This can consist of as many lines as you desire, though it is best kept to one or two so as to save paper.

The definition of the page title should be included near the top of the source document, before any regular text, typically just after the title page definition.

The definition commences with the string "^[pagetitle".  There should be no other text on this line; any text found here will be ignored.

All text entered for the page title will be rendered where it is placed.  In other words, the literal mode is automatically engaged.

Typically you would include a title for the document, a version number, a revision date, and a page number.  Some of this information may be referenced symbolically, by calling up macros defined in the header file.  Please refer to the section titled: "Text Substitution".

In particular, you would generally include the page number, optionally introducing it with text such as "Page", then some space, then the string "^[page_number".  The position of the escape character defines the position of the least significant digit of the page number, so you should allow sufficient space between the preceding text, say, "Page" and the escape character to accommodate the more significant digits of the page number.

If the "page_number" instruction appears elsewhere, it will be ignored, and an error message will be entered into the error file.

The end of the page title is identified by the string "^[end_pagetitle".  Again there should be nothing else on this line.

Partitioning Your Document

You may partition your document into named sections and subsections.  The major sections of the document are given level 0, with the major subsections of these sections being given level 1, and so on to the maximum depth at level 9.

You are to specify the start of a partition, or section, of your document, using the string "^[level" followed by a space, then the string representing the level from "0" for the major sections of the document to "9" for the most minor sections.  Following this string should be a space.  Any text after the space and before the end of the line is used as the name of the section.

If you relate this to an HTML document, level "0" corresponds to heading "h1", while level "5" corresponds to heading "h6".  The HTML specification only allows for six levels, so levels "6" to "9" are catered for using a "paragraph class" (an HTML term) named "minor_heading" to highlight these headings.

It is best to maintain a uniqueness in the section names, so that hyper-text jumps work as expected, in both the Movement Controller help system and the HTML rendering program.  A section name should be unique among all sections at the same level within the enclosing section.

The level number can be one greater than the level number of the previous "level" instruction, or less than or equal to that number.  It is an error for the level number to be greater than the previous level number by more than one.

You may elect to have a page break at the start of each major section, or at the starts all sections with level numbers equal to or less than a given value by using the string "^[page_break_for_level", followed by a space, then the string representing the level for which a page break will be generated for and for all levels up to this.

Context Sensitive Help

For the Movement Controller help system to be context sensitive, it needs to know the which sections or subsections describe which windows.  The windows are specified using the "C" language definitions used by the Movement Controller itself.  The name of the file containing these definitions is, by default, "function.inc", but may be specified on the command line to the word-processor, as an optional field to the "-i" switch.

The contents of the file will be ignored until the text "GetPassword" is found. From this point on it will gather the window names and record the corresponding numbers for each.  These numbers will be written to the help index file, along with a reference to the position within the source document, where the reference to this window was found.

These window references are generated by using the string "^[screen_number", followed by a space, then the string containing the "C" language definition, from within the ".inc" file, for this window.  There should be no other text on this line; any text found here will be ignored.

The first line used from the ".inc" file is "#define GetPassword 1".

For the help system to be able to access the relevant page for the "GetPassword" window, the string "GetPassword" should appear in the source document as the parameter to the "screen_number" instruction.  It should be positioned just after the line containing the "level" instruction for the section describing the use of this window.

As a result, the word processor will include a reference, in the index file, to this point in the source document against window "1", which is how the window would be known within the run-time Movement Controller software.

The index file also contains the full path of the source document, and indexes for the sections and subsections of this document.  In this way a site specific index file is used by the Movement Controller software to access a single source document, without having to setup links to the source document.  It is important, though, that the source document remains where it was when the word processor had been run, because that is the location in which the software will expect to find it.

As an example, the start of the section describing logging onto the computer may appear as follows:


  ^[level 1 Log Off

  ^[screen_number GetPassword
  This window is presented when the Log Off (or New User)
  option is selected from the main menu.

Cross-references and Hyper-Text

Throughout a document, you will typically wish to refer the reader to another part of the document.  When you do this you should refer to this section by its entire address, which includes all enclosing section and subsection names, separated by dots, and the entire string enclosed in double quotation marks. For example, this section would be referred to as the section titled: "Cross-references and Hyper-Text".

If the string must be broken into lines, the breaks may be made between the words of a single section name, or before the dots separating section names. If line breaks are made between words, ensure that there are no spaces beyond the last word before the line break and the end-of-line (carriage-return line-feed).

The rendering of this reference will depend on whether the manual is printed, presented via the Movement Controller's help system, or presented by an HTML rendering program.

In the printed document (whether using Rich Text Format or printer specific controls), cross-section references are presented using the section and subsection numbers, separated by dots, followed by the final subsection name, and the entire string enclosed in double quotation marks. When presented via the Movement Controller's help system, cross-section references are displayed using the final subsection name, enclosed in double quotation marks and highlighted as a hyper-text link.  When presented via an HTML rendering program, cross-section references are displayed using the final subsection name rendered as a hyper-text link.

Now, in order, to create a hyper-text link to the referenced section, the first double quotation mark of the reference must be preceded by the reference instruction, which is the string "^[reference", followed by a space.

As an example, a reference used earlier in this document might appear as follows:


  Typically you would include a title for the document, a
  version number, a revision date, and a page number.  Some
  of this information may be referenced symbolically, by
  calling up macros defined in the header file.  Please
  refer to the section titled: ^[reference "Ancillary
  Programs.The Word Processor.Writing the Input Files
  .Word-Processing Instructions.Text Substitution".

To refer to a section from another manual, the reference should be written the same way, except that you must include, between the reference instruction and the first quotation mark, some instruction to the reader, indicating that the section is in another book.  The word processor, upon finding this intervening text, will not attempt to interpret the reference, but will, instead, present the reference as it was written.

Should you wish to reference one of the standard manuals, that is the operator's manual, the technical manual, or the software manual, you should include the text, "OPERATOR'S MANUAL", "TECHNICAL MANUAL", and "SOFTWARE MANUAL", respectively.  These will be interpreted by the word processor as instructions to include "operator.htm", "technica.htm", and "software.htm", respectively, within the hypertext references to allow for hyperlinks to exist between these documents.  Similarly, the Movement Controller's online help software will recognise these and use them to, similarly, reference the corresponding header file and main source file.  For example, "OPERATOR'S MANUAL" will direct the online help to the header file, "operator.wph", and the main source file, "operator.wpi"; there is a table hard-coded within the online help software that relates these three items for each of the manuals.

Points or Bullets

You can use "points" or "bullets" to list items in your document.  We will use the term "point" rather than "bullet" in this discussion.

Each item to be presented as a point, must be preceded by the string "^[point", followed by a space, followed by the point name. The point name may be a string not containing a space, or a string commencing with an escape character followed by a double quotation mark, and terminating with the same pair of characters.

The text, of the item to be presented in the point, may either follow a space following the point name, or else may appear indented on the next line.

The point name need not be unique, and will typically be simply the string "o". This string is a special case for the HTML document, as it will be ignored; all HTML points will be displayed as unnumbered lists, followed by the point name (unless the point name is "o"), then followed by the text.

In the printed documents, and in the Movement Controller help system, each point will be introduced, with the point name presented in bold, followed by the text.  Had the text followed the point name, on the same line, then the text will be presented after the point name, and if it does not fit on a single line, the subsequent lines of the text will line up beneath the first line of text, still to the right of the point name.

Had the point's text started, indented on the line after the point name, then the indentation will be used to indent all lines of the point's text starting on the line below the point name.  If tabs appear in the indentation, they advance the indentation to the next multiple of eight spaces.

For example had you entered:


  ^[point ^["LT in/out of position^["
     This status is always present and indicates whether the
   crane is positioned on a long travel screen.

Then something similar to the following is likely to be printed:


  LT in/out of position
     This status is always present and indicates
     whether the crane is positioned on a long
     travel screen.

Whereas, had you entered:


  ^[point ^["LT in/out of position^[" This status is always
  present and indicates whether the crane is positioned on
  a long travel screen.

Then something similar to the following is likely to be printed:


  LT in/out of position This status is always
                        present and indicates
                        whether the crane is
                        positioned on a long
                        travel screen.

The point's text is either terminated with the next "point" instruction or else at the end of the paragraph.  If however you wish points to include more than a single paragraph within the point's text, you should include the string "^[point_paragraph" before the first point in the list, (or at least first point with multiple paragraphs).  On the first line after the last paragraph of the last point in the list, you should include the string "^[end_point_paragraph", this delimits the last point, whilst the "point" instruction delimited the intervening points.

If you wish a list not to be split across a page break, you should include the string "^[no_page_break_in_points" prior to the paragraph introducing the list, as the list is seen then as an extension of the paragraph.

If on another occasion, you wish to enable page breaks within a list, include the string "^[page_break_in_points" prior to the first point in the list.  When this instruction is in force, page breaks will still not break paragraphs.

It is my habit to include the "no_page_break_in_points" instruction at the beginning of the document, then bracket each list which I wish to be exempted from this with the "page_break_in_points" and "no_page_break_in_points" pair of instructions.

Text Substitution

The substitution of text is one of the two keys to being able to create site-specific documents from a single source document.  The first step in this is to define the text to be substituted, while the second step is to include references to this text throughout the document.

To define the text to be substituted, use the string "^[substitute", followed by a space, then the key string used throughout the source document (which must not include a space), then a space, then the text to be substituted for each occurrence of the key string, then the end-of-line (carriage-return line-feed).  The key string must start with the escape character to distinguish it from regular text, and is best started with a pair of escape characters to distinguish it from word processing instructions.

So, for example, consider the specification of the site name.  Typically, you would include, in the header file for that site, the following:


  ^[substitute ^[^[site_name VersaCold Cold Stores Laverton II

Now, throughout the source document, where ever you would have normally referred to the name of the site, you would now include the string "^[^[site_name".  For example, the source document may contain:


  This manual describes the operation of the ^[^[site_name
  Movement Controller.


  The software controls the Heavy-Unit-Load Conveyors and
  six cranes which comprise the load store.

After processing the source document, the resulting output files will contain something like:


  This manual describes the operation of the VersaCold
  Cold Stores Laverton II Movement Controller.


  The software controls the heavy-unit-load
  conveyors and six cranes which comprise the load
  store.

Conditional Compilation

The conditional compilation is second, and more important, of the two keys to being able to create site-specific documents from a single source document. The first step in this is to name the elements the document is to support, while the second step is to test whether these elements have been named before including the relevant sections from the source document.

To name the element, use the string "^[define", followed by a space, then the name of the element (which must not include a space).

So, for example, consider the element of the document relating to cranes. Typically, you would include, in the header file for that site, the following:


  ^[define cranes

As the word processor is only expecting to find the element name in places where normal text is not expected, there is not necessity to precede the names with a pair of escape characters.

The simplest way to use the element name is with the "if" construct.  At the start of a section, use the string "^[if", followed by a space, then the element name, then the string, "^[level", which introduces the new section, followed by the level number and section name (refer to the section titled: "Partitioning Your Document"). This will result in the processed document excluding this section, along with all its subsections, unless the element name has been defined.

For example, the subsection on cranes might start as follows:


  ^[if cranes ^[level 2 Crane Status and Control

  ^[screen_number IssueCraneCommands
  After selecting "Crane Status and Control" from the
  Operation Menu the crane status and control window will
  be presented.

Sometimes, this simple approach is not sufficient.  This is typically the case where there are options within the section.  For example, this software package comes in two styles, one built around the Microsoft DOS environment, and the other built around the X-Windows environment.  To accommodate this, we use the "^[if_block" string, followed by a space, then optionally followed by an exclamation mark, "!", to mean "not", followed by the element name, followed by the end-of-line (carriage-return line-feed).  All subsequent text will be included or excluded, depending on whether the element name has been defined and whether the exclamation mark was used or not, until the string "^[end_if_block" is encountered.  The "^[end_if_block" string should appear on a line by itself.

For an example, consider the following:


  ^[if_block x_windows
  Immediately above the location details,
  ^[end_if_block
  ^[if_block !x_windows
  Immediately below the lower legend,
  ^[end_if_block
  the restriction details are presented.

Had "x_windows" been defined, after processing the source document, the resulting output files will contain something like:


  Immediately above the location details, the
  restriction details are presented.

Whereas, had "x_windows" not been defined, after processing the source document, the resulting output files will contain something like:


  Immediately below the lower legend, the
  restriction details are presented.

The stand-alone word processor manual is produced from the main source file, "technica.wpi", by providing its own header file, "wp.wph", that sets definitions that are tested within "technica.wpi" to set substitutions that reduce the level numbers for the word processor section so that its major subsections are promoted to the major subsections of the whole document.  If you find this of interest, please refer to the file, "wp.wph", where it defines "wp_only" and to "technica.wpi" and see how it uses "wp_only" to discard all but the word processor section and to promote its subsections.

Text Presentation Options

This word processor does not offer a wide variety of fonts, and other "pretties" but instead concentrates on getting the important part of the job done. However, some text presentation options are essential.

This word processor supports the following text presentation options:

  • bold
  • compress
  • italic

The string "^[bold" is used to mark the start of the range of text to be rendered bold, while the string "^[end_bold" is used to mark the end of this range.

The string "^[compress" is used to mark the start of the range of text to be rendered more compressed, while the string "^[end_compress" is used to mark the end of this range.

The string "^[italic" is used to mark the start of the range of text to be rendered in italics, while the string "^[end_italic" is used to mark the end of this range.

When using multiple options it is best to end them in the reverse order to which they were selected, so that if "bold" is enabled, then "italic", then you should disable "italic" before disabling "bold".

It is an error for any of these text presentation options to be still in force at the end of the document.

Placing Text Explicitly

Normally any amount of horizontal white space is compressed into a single space, and all non-blank lines are treated as a single line to be broken up into the lines of a single paragraph, while one or more blank lines, equivalently, delimit a paragraph, yielding a single blank line between the paragraphs.

This is normally what you would want to happen, however, on odd occasions, you will want to be able to place characters in explicit locations.

To do this, use the string "^[literal".  You would normally place an end of line at this point so as to have a reference point from which to space your text.  Macros will continue to be recognised throughout the text from this point.

In placing your text, it is best to not extend too far across the line, as the document may need to be rendered on a narrow medium at some time.

After the text which is to be placed explicitly, include the string "^[end_literal".

An example would be:


  Include the following statements in the system configuration
  file "C:\CONFIG.SYS":^[bold^[literal
            DEVICE=C:\DIGI\XIDOS5.SYS
            BUFFERS=20,0
            FILES=30
            LASTDRIVE=C
            FCBS=4,0
            STACKS=9,256^[end_literal^[end_bold

After processing the source document, the resulting output files will contain something like:


  Include the following statements in the system
  configuration file "C:\CONFIG.SYS":

            DEVICE=C:\DIGI\XIDOS5.SYS
            BUFFERS=20,0
            FILES=30
            LASTDRIVE=C
            FCBS=4,0
            STACKS=9,256

Whereas, had the "^[literal" and "^[end_literal" instructions been omitted, after processing the source document, the resulting output files will contain something like:


  Include the following statements in the system
  configuration file "C:\CONFIG.SYS":
  DEVICE=C:\DIGI\XIDOS5.SYS BUFFERS=20,0 FILES=30
  LASTDRIVE=C FCBS=4,0 STACKS=9,256

Note that when rendering the document under Netscape Communicator, in spite of specifying pre-formatted text and true-type font, the text is still not accurately positioned.  The Microsoft Internet Explorer seems to be more well-behaved in this respect, as is the printed form of the document and the rendering of it via the Movement Controller's help system.

Presentation of Text Screens

Many of the windows presented by the Movement Controller software are basically text screens.  In the DOS system, these screens are 25 lines by 80 characters.  In the X-Windows system, the screen size is variable.  As a result, we present all text screen dumps in the 25 x 80 arrangement.

Screen dumps are started with the string "^[screen" on a line on its own, followed by the 25 lines of the screen dump, followed by the string "^[end_screen" also on a single line.

Upon processing, the characters of the intervening 25 lines are "compressed" and placed within a box containing 25 lines by 80 characters.  The distance, of each character from the left of the column in the source document, determines where it will be placed relative to the left side of the box. As a result, there should be no characters placed beyond column 80 in this portion of the source document.

Because the characters are compressed, the full screen width of 80 characters will be presented even though normally fewer characters can be accommodated across a page.

When presenting these in HTML, a blue background is provided, however Netscape Communicator does not extend the blue background to the full 80 columns unless the text also extends that far - not just spaces.  Also Netscape has trouble presenting some of the extended IBM character set.

The paragraph immediately preceding the "^[screen" line, should be brief and serve no other purpose than to introduce the screen dump.  This is because both this paragraph and the screen dump will not be presented by the Movement Controller's help system.

Presentation of Pictures

In order to present full graphical screen dumps, or other images, use the string "^[extra_page", followed by a space, followed by the filename of the ".gif" file (without the extension), followed by another space, then the caption of the image, followed by the end-of-line (carriage-return line-feed).

When processing this for printing, the output files will contain some substantially blank pages, save the page title and the caption for the image. It is intended that these pages be fed into the printer again to have the image printed on them via some other software.  There will be a note in the output, at the position of the "^[extra_page" instruction, to refer to the image on the following page.

On the other hand the HTML file will reference the nominated ".gif" file so that, provided the file exists, the HTML rendering program will present the image in the document in its proper position.

It is intended that the ".gif" file exists in the directory dedicated to the site, so that relevant images may be presented for the site.

When producing the RTF file, you should use a third-party's word processor to save the ".gif" file as an ".rtf" file with the same name stem as the original ".gif" file.  These ".rtf" files will be referred to as subdocuments of the RTF file being produced, and be presented on the page following their reference with the appropriate page title and picture caption.

Page Formatting

The page formatting instructions affect the printer output files only.  These instructions are typically included at the top of the source document, each on a separate line.  The instruction strings are:

  • "^[lines_per_page"
    The number of line on a page, including the top and bottom margins.  Default value is 63.
  • "^[left_margin   "
    The blank characters to leave at the left of the page.  Default value is 10.
  • "^[right_margin  "
    The number of columns across the page including the left marign.  Default value is 75.
  • "^[top_margin    "
    The number of blank lines to leave at the top of the page.  Default value is 10.
  • "^[bottom_margin "
    The number of blank lines to leave at the bottom. The difference between the number lines per page and the bottom margin is the only value of importance.  For example, if there are three lines which must be left at the bottom of the page it make no difference whether the number of lines per page is 66 and the bottom margin is 3 or the number of lines per page is 63 and the bottom margin is 0.  Default value is 0.

Each of these strings is to be followed by a space, then the specification of the quantity.  For example, the source document might start with the lines:


  ^[lines_per_page 60
  ^[left_margin 10
  ^[right_margin 75
  ^[top_margin 0

When producing an RTF document, these values are discarded.  Instead, the margins are specified relative to the edges of the paper, in twips (1440ths of an inch). In addition, the number of columns and rows are also to be specified, and the point sizes for the regular and condensed fonts. on a separate line.  The instruction strings are:

  • "^[rtf_n_columns           "
    The number of characters to be printed across a single line, excluding the left and right margins, for an RTF file. Default value is 85.
  • "^[rtf_n_lines             "
    The number of lines to be printed on a page, excluding the top and bottom margins, for an RTF file.  Default is 63.
  • "^[rtf_left_twips          "
    The number of twips (1440ths of an inch) of paper to be left at the left of a page.  Default is 1008 (0.70inches, 17.8mm).
  • "^[rtf_right_twips         "
    The number of twips (1440ths of an inch) of paper to be left at the right of a page.  Default is 1008 (0.70inches, 17.8mm).
  • "^[rtf_top_twips           "
    The number of twips (1440ths of an inch) of paper to be left at the top of a page.  Default is 850 (0.59inches, 15mm).
  • "^[rtf_bottom_twips        "
    The number of twips (1440ths of an inch) of paper to be left at the bottom of a page.  Default is 850 (0.59inches, 15mm).
  • "^[rtf_regular_font_size   "
    The size of the font used for most of the printing.  Default is 20.
  • "^[rtf_compressed_font_size"
    The size of the font used for compressed printing (whether implicitly requested for ASCII screen dumps, or explicitly requested).  Default is 13.

Each of these strings is to be followed by a space, then the specification of the quantity.  For example, the source document might include the lines:


  ^[rtf_left_twips 850
  ^[rtf_right_twips 850
  ^[rtf_top_twips 850
  ^[rtf_bottom_twips 850

Customising for Your Printer

These instructions are expected to reside in the printer configuration file.  The first instruction is the printer initialisation instruction, which starts with the string "^[substitute ^[initialise_printer", followed by a space, then followed by the printer initialisation string.  Typically this string will contain escape sequences to select portrait mode, set the font, the print weight and so on.

This string is included at the start of each printer output file.  If no initialisation string is specified, then no initialisation string is included in the printer output files.  This is as would be required for the early IBM dot-matrix printers originally supplied for IBM PCs.

The other instructions for the printer, to be included in the printer output files, are the instructions to enable and disable the text presentation options "bold", "italic", and "compress".

You can use the "^[substitute" instruction, followed by a space, followed by one of the instructions to enable or disable a text presentation option, followed by another space, then followed by the string required by the printer to achieve this, followed, finally, by the end-of-line (carriage-return line-feed).

If you do not include these instructions, the default behaviour is to produce output suitable for a printer in IBM emulation mode; that is a printer emulating the behaviour of an early IBM PC dot-matrix printer.

For example, the printer configuration file for an HP DeskJet might include the following lines:


  ^[substitute ^[initialise_printer ^[&126A^[&k0G
  ^[&s1C^[&l0O^[(10U^[&l66P^[&l3E^[&l63F^[*o1M^[(
  s0P^[(s0S^[*v1S^[(s3T^[&l6D^[&l8C^[(s12V^[&k12H
  ^[(s10H
  ^[substitute ^[compress ^[&k8H^[(s15H
  ^[substitute ^[end_compress ^[&k12H^[(s10H
  ^[substitute ^[bold ^[(s7B
  ^[substitute ^[end_bold ^[(s0B
  ^[substitute ^[italic ^[(s1S
  ^[substitute ^[end_italic ^[(s0S

Note that in the above example, the first four lines should be a single line with no intervening spaces.

In this example, the escape sequences for "^[initialise_printer" select the following options:

  • ISO A4
  • CR=CR, LF=LF, FF=FF (this is essential)
  • No end of line wrap
  • Portrait, not Landscape
  • PC-8 font (this calls up the characters used in the BIOS of IBM compatible computers to correspond to the extended ASCII codes from 128 to 255, and is essential for most of my own manuals)
  • 66 lines per page
  • 3 blank lines at the top of the page
  • 63 lines of text, leaving no blank lines at the bottom of the page
  • Normal presentation, not draft
  • Fixed character pitch (this is essential)
  • Upright style - not italic (this is essential)
  • True black
  • Courier
  • 6 lines per inch
  • 8/48 inches per line
  • 12/72 point size
  • 10 characters per inch

The page setup must allow the printer to fit a page of output from the word processor on a single printed page.  The number of lines down a page, and characters across a page can be specified for the document.  I, typically, specify 60 lines of 65 characters, beyond a margin of 10 characters, giving a total width (or right margin) of 75 characters.  My manuals also include some wider lines for which the "^[compress" escape sequences are called in to allow these to fit in the same physical space.

The escape sequences for "^[compress" select 16 characters per inch, while those for "^[end_compress" return to 10 characters per inch.

Creating a Printout and the Help System

After creating the input files, it is then time to process these to create the output files.  Most commonly, the output files to be produced will be those to be copied to the printer and that to assist the Movement Controller help system to access the source document.

To do this first ensure the current working directory is the directory corresponding to the site for which you wish to create the output files, then issue a command similar to the following:


  wp -i operator.wph deskjet.pcl operator.wpi

When you tire of issuing such a command, create a script or batch file to contain this command.

The first field is the filename of the word processor.  In the above example, the word processor is assumed to be located in one of the directories listed in the "PATH" environment variable.

The fifth field is a "switch", which commences with the Unix switch identifier, "-", followed by the switch name "i" (for index), followed, optionally and directly, by the file name of a "C" language file which contains the definitions of the names used to refer to the windows presented by the software.  If no file is specified, the file, "function.inc" from the directory in which the source document resides, is used.  This switch is optional, and if not implemented, the word processor will not produce index information for the Movement Controller help system.

The next field is the header file, which, in the above example, is "operator.wph".  This assumes the header file is located in the current working directory.  This would normally be the case, as the current working directory should be the one dedicated to the specific site, and it is in the current working directory that the output files will be created.  This file is optional.  The name of the header files for the operator and technical manuals must be "operator.wph" and "technica.wph", respectively, if they are to be recognised by the Movement Controller help system.

Next comes the printer configuration file, specified using its full path name. In the above example, this is "deskjet.pcl".  This assumes the printer configuration file is located in the current working directory.  This would not normally be the case, as the current working directory should be the one dedicated to a specific site, whereas all printer configuration files would be located in a single directory, possibly that dedicated to the software package, or a sub-directory of it.  This file is optional, and if not implemented, the word processor will produce output suitable for an IBM PC printer, or a printer emulating one.

After the printer configuration file should be the full path name of the source document.  In the above example the source document, "operator.wpi", is located in the current working directory.  This would not normally be the case, as the current working directory should be the one dedicated to a specific site, whereas the source document would be located in a directory dedicated to the software package.

You may, explicitly nominate the output filename, using the "-o" switch.  Any extension on that filename is ignored.  The output files are each provided with unique extensions.

The names of the printer output files, if not specified explicitly, are copied from the main source document filename, with any path and its extension removed.  The extensions, ".all", ".odd", ".evn", and ".nve" are appended to it.  These files will reside in the current working directory, unless the output filename had been explicitly specified.

The name of the Movement Controller help system index file, is based on the main source file's name, with any path information and its extension removed, with the extension, ".ndx".  The word processor must be able to open the nominated (or default, if no file was nominated) "C" language window name definition file.

Creating the HTML Document

After creating the input files, it is then time to process these to create the output files.  Instead of creating the output files to be copied to the printer and that to assist the Movement Controller help system, you may create an HTML version of the document.

To do this first ensure the current working directory is the directory corresponding to the site for which you wish to create the output files, then issue a command similar to the following:


  wp -phtml operator.wph operator.wpi

The first field is the filename of the word processor.  In the above example, the word processor is assumed to be located in one of the directories listed in the "PATH" environment variable.

The second field is a "switch", which commences with the Unix switch identifier, "-", followed by the switch name "phtml" (for produce an HTML file).  This switch overrides the index switch ("-i"), and if present, no printer output files will be generated and nor the help system index file.

The next field is the header file, which, in the above example, is "operator.wph".  This assumes the header file is located in the current working directory.  This would normally be the case, as the current working directory should be the one dedicated to the specific site, and it is in the current working directory that the output files will be created.  This file is optional.

Next comes the full path name of the main source document.  In the above example the source document, "operator.wpi" is located in the current working directory.  This would not normally be the case, as the current working directory should be the one dedicated to a specific site, whereas the source document would be located in a directory dedicated to the software package.

You may, explicitly nominate the output filename, using the "-o" switch.  Any extension on that filename is ignored.  The output files are each provided with unique extensions.

The name of the HTML output file, if not specified explicitly, is copied from the main source document filename, with any path and its extension removed. The extension, ".htm" is appended to it.  Similarly, the extension, ".php", is used for its accompanying PHP file.  These files will reside in the current working directory, unless the output filename had been explicitly specified.

The HTML output file includes the title page, then the table of contents.

After the table of contents, follows the document proper.

Required Contents of the Style Sheet File

There should be a style sheet file, called "Woodgrove.css", residing in the current working directory.

Below is an example of suitable contents for this file:


  body {
          font-family:"Trebuchet MS",sans-serif;
          font-size:12.0pt;
          font-weight:normal;
          color:#336633;
          background-repeat: repeat;
          background-position: center}
  p, li, div,h1,h2,h3,h4,h5,h6 {
          margin-top:6.0pt;
          margin-right:0cm;
          margin-bottom:3.0pt;
          margin-left:0cm}
  h1 {
          font-size:20.0pt}
  h2 {
          font-size:16.0pt}
  h3 {
          font-size:12.0pt}
  h4, h5, h6 {
          font-size:10.0pt}
  a:link {
          color: red;
          text-decoration:underline;
          text-underline:single}
  a:visited {
          color: blue;
          text-decoration:underline;
          text-underline:single}
  p.minor_heading {
          font-size:10.0pt;
          margin-top:1.0pt;
          margin-bottom:1.0pt}
  p.table_of_contents {
          font-size:10.0pt;
          margin-top:1.0pt;
          margin-bottom:1.0pt}
  p.screen_dump {
          font-family:"MS Courier New";
          font-size:8.0pt;
          color: black;
          background-color: #0080ff}
  table.list_of_links {
          font-size:10.0pt}

You are free to add to this and to alter most details, however, you should be careful about what you delete.  For example, you may wish to modify or delete the "background:" statement, however, if you do delete it, you should remove the "background-repeat:" and "background-position:" statements as well, and ensure that the semi colon (";") which follows the "color:" statement is replaced with a close brace ("}").

The paragraph class "minor_heading" is used for those subsections which are at levels lower than those defined for HTML.  HTML supports up to 6 levels of document partitioning, whereas this word processor supports up to 10 levels.

The paragraph class "table_of_contents" is used for the two tables of contents.

The paragraph class "screen_dump" is used for the presentation of the contents of text windows (incorporating the extended IBM PC character set).  It is important that the font chosen for this purpose be a fixed pitch one.

Creating a Rich Text Format File

After creating the input files, it is then time to process these to create the output files.  Instead of creating the output files to be copied to the printer and that to assist the Movement Controller help system, you may create an RTF version of the document.

To do this first ensure the current working directory is the directory corresponding to the site for which you wish to create the output files, then issue a command similar to the following:


  wp -prtf operator.wph operator.wpi

When you tire of issuing such a command, create a script or batch file to contain this command.

The first field is the filename of the word processor.  In the above example, the word processor is assumed to be located in one of the directories listed in the "PATH" environment variable.

The second field is a "switch", which commences with the Unix switch identifier, "-", followed by the switch name "prtf" (for produce an RTF file).  This switch overrides the index switch ("-i"), and if present, no printer output files will be generated and nor the help system index file.

The next field is the header file, which, in the above example, is "operator.wph".  This assumes the header file is located in the current working directory.  This would normally be the case, as the current working directory should be the one dedicated to the specific site, and it is in the current working directory that the output files will be created.  This file is optional.

This should be followed by the full path name of the main source document.  In the above example the main source document, "operator.wpi", is located in the current working directory.  This would not normally be the case, as the current working directory should be the one dedicated to a specific site, whereas the source document would be located in a directory dedicated to the software package.

The name of the RTF file is copied from the main source document filename, with any path and its extension removed.  The extension, ".rtf" is appended to it. This file will reside in the current working directory.

Using the Version and Change Log Files

There is a log of changes made to the software that is posted on the website. The latest change number in that log, I use as the version number for the manuals.  The change log, itself, I include at the end of the software manual.

There is an ancillary program for the Movement Controller that reads the change log from the PHP file, where it is prepared for presentation on the website, and creates a word-processing source file (a header file) for the manuals that will set the version and date and creates another word-processing source file that provides the change log as a set of points (see "Points or Bullets").

The main source document needs to be adjusted to make proper use of these files as is described in the section of the TECHNICAL MANUAL titled: "Appending the Change Log to the Software Manual".

Then, to word process these files, these files will need to be listed among the source files for the word processor.  For example, to include the version and date specification file for the generation of the various forms of the operator's manual, you would use the following three command lines:


  wp -i     operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\deskjet.pcl
                         ..\cnmmouse\operator.wpi
  wp -prtf  operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\operator.wpi
  wp -phtml operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\operator.wpi

And to include both the version and date specification file and the change log file for the generation of the various forms of the software manual, you would use the following three command lines:


  wp -i     software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\deskjet.pcl
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi
  wp -prtf  software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi
  wp -phtml software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi

The above examples have been presented as split across two or more lines. The commands, however, are not to be split across multiple lines.

the generation of the various forms of the operator's manual, you would use the following three command lines:


  wp -i     operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\deskjet.pcl
                         ..\cnmmouse\operator.wpi
  wp -prtf  operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\operator.wpi
  wp -phtml operator.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\operator.wpi

And to include both the version and date specification file and the change log file for the generation of the various forms of the software manual, you would use the following three command lines:


  wp -i     software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\deskjet.pcl
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi
  wp -prtf  software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi
  wp -phtml software.wph ..\cnmmouse\version.wph
                         ..\cnmmouse\software.wpi
                         ..\cnmmouse\changelg.wpi

The above examples have been presented as split across two or more lines. The commands, however, are not to be split across multiple lines.