Omni Systems, Inc. |  | Mif2Go User's Guide, Version 55 |  |  |  |  |

> 4 Editing configuration files > 4.4 Understanding the rules for configuration settings

## 4.4 Understanding the rules for configuration settings

Every Mif2Go configuration file must begin with at least one line of header text, even if it is an empty line. The content of the line does not matter to Mif2Go, as long as it does not duplicate the name of a configuration section.

After the header text, each configuration file contains a series of sections. Each section consists of a section name in square brackets, followed by a list of settings of the form Key=Value or Key=Command, each on a separate line; and possibly by one or more comments:

[Section]

Key = Value

Key = Value1 Value2 Value3 ...

Key = Command

; Comment

Section names may not contain spaces or punctuation. The opening bracket for each section name must be in column 1.

Keep in mind these Microsoft rules for configuration files:

• Section names must be unique; if there are duplicate section names in a configuration file, only the first instance is processed.

• Key names must be unique in a section; if you repeat a key name in the same section, only the first instance is processed.

And these Mif2Go rules:

• The first line in the file must be a comment; Mif2Go requires a header line.

• No more than one space after the equals sign; otherwise, bad things can happen:

– If the value is Boolean (Yes/No), Mif2Go treats it as No, even if you typed Yes.

– If the value is a string, all spaces after the first are included in the string.

Consider all of the following:

Section names must be unique

Key names must be unique in a section

Key names must be valid ASCII

Key names are not case sensitive, by default

Fixed-key sections differ from variable-key sections

Order of settings can be important for variable keys

Formats must be in catalogs

Multiple values are separated by spaces

Spaces and tabs: some retained, some removed

Comments start with a semicolon

Boolean values can be expressed various ways

Section names must be unique

Section names must be unique. If you use the same section name twice in your configuration file, only the first section is processed. Otherwise, order of sections does not matter, except for macro sections (see §28.1.1.2 Understanding where you can define named macros).

Key names must be unique in a section

Each Key= setting in a given section must be the only setting for that key in that section. A common error is to add a setting to a section that already has a setting for that key. For example, any repeated lines assigning additional values to the same format name are ignored; only the first line is processed. Instead, place any additional values on the same line as the first, separated by spaces.

Key names must be valid ASCII

All ASCII characters are valid in key names, with the following exceptions:

• “?” and “*” are treated as wildcards, unless you turn off wildcard usage; see §5.1.7 Specifying how to treat cases, spaces, and wildcards. (However, when you override a configuration setting with a configuration variable, Mif2Go does not recognize wildcards in the key name; see §33.2.4 Assigning values to configuration variables.)

• “;” or “[” must be prefixed with escape character “\” if you want to start a key name with either of these characters.

Spaces are nominally allowed in key names, but the spaces are ignored unless you turn off [Options]SpacelessMatch; see §5.1.7 Specifying how to treat cases, spaces, and wildcards. Do not use spaces if you can possibly avoid them.

Key names are not case sensitive, by default

Comparisons of key names are caseless, unless you turn on case sensitivity; see §5.1.7 Specifying how to treat cases, spaces, and wildcards. (However, when you override a configuration setting with a configuration variable, the key name is case sensitive; see §33.2.4 Assigning values to configuration variables.)

Fixed-key sections differ from variable-key sections

Configuration files contain two kinds of sections: those with fixed keys (key names predefined by Mif2Go) and those with variable keys. For example, sections such as [HTMLOptions] and [WordOptions] are for settings with fixed key names; sections such as [HTMLParaStyles] and [HelpStyles] are for settings with key names you specify, typically names of FrameMaker formats.

Order of settings can be important for variable keys

In a fixed-key section, the order of settings does not matter. Order is important only in sections where you can use variable keys, and usually only if you use wildcards in key names (see §4.6 Using wildcards in configuration settings). However, there are exceptions; for example, see §29.4.2 Observing restrictions on redefining marker behavior.

Formats must be in catalogs

Often the variable-key names you specify are names of formats in your FrameMaker document, such as paragraph, character, or table formats. Make sure each format you use for a key name actually appears in the appropriate catalog in FrameMaker; Mif2Go cannot process formats that are not in a FrameMaker catalog.

Multiple values are separated by spaces

Some variable-key sections allow multiple values for each key: sections such as [HTMLParaStyles], [WordStyles], and [HelpStyles], where you can assign multiple properties to each FrameMaker format. Use spaces between values.

Spaces and tabs: some retained, some removed

Mif2Go treats spaces and tabs in configuration settings as follows:

• Spaces and tabs before the Key and before the equals sign are ignored, unless [Options]SpacelessMatch=No, in which case those before the Key are not ignored (see §5.1.7 Specifying how to treat cases, spaces, and wildcards).

• If the equals sign is followed by one or more spaces or tabs, the first such space or tab is removed, and the rest are treated as part of the value. Put no more than one space after the equals sign. If you want to align settings vertically for readability, put extra spaces before the equals sign, not after.

• All spaces and tabs that follow a value are retained in the output.

• Do not try to indent settings in your project configuration file. When Mif2Go updates this file, Windows rewrites the file, and deletes all leading spaces in the settings. You can use indentation in macro definitions in other configuration files and macro libraries.

Comments start with a semicolon

Lines that start with a semicolon “;” are comments. For a line to be treated as a comment, the semicolon must be the first character on the line (no leading blanks or tabs). Mif2Go pays no attention to comment lines; you can use them to add your own notes. However, do not try to “comment out” a section by inserting a “;” in front of the section name; all settings that follow such a line, up to the next line that starts with a “[”, would be added to the settings for the preceding section. To comment out a section, see §4.7 Commenting out configuration sections.

Boolean values can be expressed various ways

For an On/Off value, Mif2Go recognizes “1” (numeral one), “Yes”, and “True” as On, and “0” (zero), “No”, and “False” as Off.

> 4 Editing configuration files > 4.4 Understanding the rules for configuration settings

| Mif2Go User's Guide: 4.3 Understanding where project settings come from |  | Mif2Go User's Guide: 4.5 Specifying file paths in configuration settings |