Path and file names should conform to the requirements listed in §1.1.2 File, directory, and path names, otherwise you risk run-time errors. Additional considerations:
Path separator can be “\” or “/” (except sometimes!)
Paths that contain spaces must be quoted
Paths to configuration templates should be absolute
Some relative paths relate to the configuration file location
Most other paths relate to the project directory
Paths to other applications must be absolute.
Path separator can be “\” or “/” (except sometimes!)
When you specify a file path in a configuration setting, you can use either a backslash “\” or a forward slash “/” as a separator character. A forward slash is preferred, except in the following cases, where you must use a backslash:.
In Windows API calls, forward slashes work fine, because the original Windows programmers compiled Windows on VAX/VMS machines.
Note: XML catalog-key path settings must use forward slashes. See §4.1.1 Connecting to XML catalogs
Paths that contain spaces must be quoted
If a path contains any spaces, enclose the entire path in quotes. See §1.1.2 File, directory, and path names.
Paths to configuration templates should be absolute
Settings that reference configuration templates, or other files in the DITA2Go distribution directory structure, should use absolute paths that begin with environment variable %OMSYSHOME%; for example:
Configs = %omsyshome%\d2g\local\config\local_d2htm_config.ini
See §1.3.1 Set up a framework for Omni Systems applications.
Some relative paths relate to the configuration file location
Relative paths in the settings listed in Table 3-1 are relative to the location of the configuration file in which the setting occurs. This means that if you move such a setting from one configuration file to another at a different level in your project directory structure, the path will no longer be correct. For this reason, it is safer to make these paths absolute.
If you want project portability, the price is using a fixed directory structure, where both the _config directory (see §39.3.3 Deciding where to keep document-specific configuration files) and the project directory are immediately below the source directory. If you have files all over the place, portability becomes impossible.
Most other paths relate to the project directory
Most path settings, other than those listed in Table 3-1, can be either relative or absolute. Relative file paths can make your conversion project portable. Many support issues arise when a project is moved, after which some buried links stop working.
When you specify a relative file path in a configuration setting, with the exception of settings listed in Table 3-1, the path is relative to the project directory. However, there is one additional exception:[Automation]ShipPath is relative to the wrap directory; see §44.3 Understanding path values for deliverables.
Paths to other applications must be absolute
File paths to non-DITA2Go executables must be absolute. However, a better way would be to make sure those executables are on your system PATH, so your conversion project is portable.