FlexDoc/XML - XSDDoc - FAQ

Generator Settings

What is Generator GUI?

When you run generator.bat (as described in How to run XSDDoc?), you will see this following dialog window:

That is called Generator Dialog. Together with all other windows invoked from it everything is called Generator GUI.

The main purpose of Generator GUI is to provide a user friendly way to specify/edit various generator settings, as well as to run the generator itself (by clicking «Run» button) and track the generation progress:

See Also:

What is generator.config?

All settings specified/edited in the Generator GUI are not passed to the generator directly. Rather, they are stored in the generator configuration file, which by default is:
{flexdoc-xml}/config/generator.config
where '{flexdoc-xml}' is FlexDoc/XML installation directory. The new settings are saved in the generator.config either before running the generator (by clicking «Run» button) or when you exit the Generator Dialog (by clicking «Exit» button). When the generator starts, it reads all settings from that file.

So, the entire Generator GUI serves just as an editor of generator.config and the generator launcher.

But the default generator.config is not the only possible. With -config command line option you can specify a different generator configuration file, which will be read/edited by the Generator GUI and passed to the generator launched from it. That allows you easily switching between different generator configurations.

See Also:

How to suppress Generator GUI?

Of course, in many situations you don't need any GUI, rather just to run the generator itself from Java command line (for instance, when you run XSDDoc as part of some automatic build process).

You can suppress the appearance of Generator GUI using -nodialog command line option. For instance, here is how you should modify the last command in the supplied generator.bat:

"%JAVA_HOME%\bin\java" %JAVA_OPTIONS% -cp "%CLASS_PATH%" xyz.flexdoc.xml.Generator -nodialog
In that case

What are Template Parameters?

Template parameters are those generator settings that are handled entirely in templates. The generator (its Java-hardcoded part) doesn't understand their meaning. It just reads the parameter definitions from the main template and knows from that how to parse their values and pass to the template.

By those definitions also the Parameter Inspector is built (which is invoked from the Generator Dialog by «Params» button):

The parameter values edited in the Parameter Inspector are stored generator.config file.

See Also:

What are Output Format Options?

Output format options are those generator settings that are handled by the generator itself (its Java-hardcoded part) and relevant only to the selected output format. Most of them are not accessible in templates. However, in other respects format options are similar to template parameters.

In the generator GUI they are specified/edited in a Format Option Inspector, which is organized the same as the Parameter Inspector and invoked by «Options» button in the Generator Dialog. Then, the edited option values are stored the generator.config file.

Alternative, an output format option can be specified directly on the generator command line by its name (found in the description pane of the Option Inspector) using -o option, e.g.:

-o:html.output.css.file.pattern=C:\flexdoc-xml\templates\XSDDoc\css\azure-theme.css
or
-o:html.output.css.file.pattern "C:\flexdoc-xml\templates\XSDDoc\css\azure-theme.css"

See Also:

HTML Options

When in Generator Dialog you select HTML output format and click «Options» button, you will see the following HTML Option Inspector dialog (click on the screenshot to see the corresponding option description):

The descriptions of HTML options (the default option values are underlined):

Option Name / Type / Description
Output The options to control various properties of the generated HTML output as a whole.
Markup html.output.markup : enum {"html401", "xhtml1"}

Specify the (X)HTML markup version of the generated output.

Possible Choices:
"HTML 4.01"
This is the default setting. The output files will be generally compatible with one of these Doctypes:
  • HTML 4.01 Transitional
  • HTML 4.01 Frameset

The incompatibility may come from the HTML markup found in the text coming from the data source (e.g. doc-comments). To fix the syntax errors (like missing closing tags) automatically, you can use the option: Text | Render Embedded HTML | Fix markup

"XHTML 1.0"
The output files will be generated according to one of the Doctypes:
  • XHTML 1.0 Transitional
  • XHTML 1.0 Frameset
This format also implies the mandatory/default settings for the following options:
  • Output | Add charset = true.

    The charset must always be specified in XHTML.
  • Text | Render Embedded HTML | Fix markup = true (default).

    If HTML markup embedded in input text is allowed to format the generated output, then, in the case of XHTML output it must be parsed and converted into XHTML too (e.g. simple tags must have proper XML endings "/>"). That means, any inconsistencies found in the embedded HTML (e.g. a missing closing tag) will be fixed on the way.
Character Encoding html.output.encoding : string

Specifies the encoding of the generated HTML files. The name should be a preferred MIME name (canonical name) as given in the IANA Registry. When the encoding is not specified, the Java machine's default encoding will be used. (Its name appears as the default value of this option.)

Add charset html.output.addCharset : boolean

Specifies whether to insert the character encoding declaration in the generated HTML files. The encoding name will be taken from the option: Character encoding

For example, when this option is selected (true) and the value of the "Character encoding" option is "ISO-8859-1", the following line will be inserted in the head of every generated HTML document:

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
Add Mark of the Web html.output.addMarkOfTheWeb : boolean

When this option is specified, the generic Mark of the Web (MOTW) comment will be added to all generated HTML documents (except the root frameset HTML).

Suppress timestamp html.output.noTimeStamp : boolean

Specifies whether to suppress the date/time information included in a special comment inserted automatically at the beginning of every generated HTML file, which looks as the following:

<!-- Generated by FlexDoc/XML 1.12 on Mon Feb 12 20:57:43 CET 2018 -->
When this option is selected (true), such a comment is still inserted, however without the current date/time:
<!-- Generated by FlexDoc/XML 1.12 -->
HTML pattern file html.output.documentPatternFile : file pathname

This option allows you to frame the output generated by FlexDoc into your own HTML file. This may be useful when you need to insert into the generated HTML some extra lines with special settings.

To do this, you will need to prepare a special HTML pattern file with the content as follows:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <!-- a custom style sheet -->
  <link href="${flexdoc-doc-root}/mystyle.css" rel="stylesheet" type="text/css">
  ...
  <!-- flexdoc-html-head -->
</head>
<body>
  <!-- flexdoc-html-body -->
</body>
</html>
The lines:
<!-- flexdoc-html-head -->
<!-- flexdoc-html-body -->
are obligatory because they are replaced with the actual HTML head and body blocks generated by FlexDoc.

Anything else is up to you to fill in. Just make sure your markup is valid HTML or XHTML (if you selected one; see option: Output | Markup).

You may also use a few macros expanded to the values provided by FlexDoc:

Macro Description
${flexdoc-doc-root} Expanded to the relative pathname leading from the given HTML file to the documentation root directory.

This macro will allow you, for instance, to specify your custom CSS file, which you can place in the documentation root and use it to format the HTML markup embedded in your descriptions/annotations.

Note: A different possibility to add your custom styles is via the CSS pattern file. See option: Output | CSS | Generate style sheet file | CSS pattern file.

${flexdoc-encoding} Expanded to the name of the character set used in the generated HTML document (e.g. UTF-8). It is the same as specified with the option: Output | Character Encoding. This macro may be useful particularly in case of XHTML to specify the XML declaration in your HTML pattern file, e.g.:
<?xml version="1.0" encoding="${flexdoc-encoding}"?>
Once your HTML pattern file is ready, you should specify it with this option. Then, it will be used to generate all HTML document files. Note that the generation of the frameset HTML file (normally 'index.html') is not affected by this setting.
CSS The group of options related to formatting of HTML output, which is done through Cascading Style Sheets (CSS).
For details, see: FlexDoc.XYZ | Documentation | Usage of CSS in generated HTML | HTML Generator Options for CSS
Generate style sheet file html.output.css.file : boolean

Specify whether to generate the external CSS file (global style sheet).
For full description, see: HTML Generator Options for CSS | <this option>

CSS pattern file html.output.css.file.pattern : file pathname

Specify a CSS pattern file to frame the generated global style sheet into your own CSS file.
Include anonymous rules html.output.css.file.anonymRules : boolean

Specify whether all generated anonymous CSS rules must be stored in the external CSS file (global style sheet).
For full description, see: HTML Generator Options for CSS | <this option>

Generate named rules html.output.css.namedRules : enum {"none", "all", "selected"}

Specify whether to generate named CSS rules.
For full description, see: HTML Generator Options for CSS | <this option>

Include descriptions html.output.css.namedRules.descriptions : boolean

Specify whether to add the descriptions of template formatting styles to the named CSS rules generated from them.
For full description, see: HTML Generator Options for CSS | <this option>

Custom rule file html.output.css.namedRules.customRuleFile : file pathname

Specify a (CSS) file with custom definitions for some of the automatically generated default and named CSS rules.
For full description, see: HTML Generator Options for CSS | <this option>

Units html.output.css.units : enum {"relative", "pixels", "points"}

Specify measurement units used in the generated HTML.
For full description, see: HTML Generator Options for CSS | <this option>

Text The group of options to control the processing of text (character data) supposed for printing in the output.
Render embedded HTML html.text.renderEmbeddedHTML : boolean

Specifies whether to render (interpret) embedded HTML markup.

Embedded HTML markup are HTML tags found in the plain text supposed for printing in the output. Such text typically comes directly from the data source (e.g. doc-comments or annotations). However, it may be specified in templates as well. Rendering of that HTML markup means adding the formatting encoded with it to the primary formatting specified in templates.

When this option is true (checked), all custom HTML tags will be passed to the output as is. That means, all your XHTML tags specified in your XSD annotations will be converted to normal HTML tags and get into the output exactly where you specified them (including all attributes).

When this option is false (unchecked), all custom HTML tags will be converted to ordinary text and printed in the output. So, you will be able to see what your HTML tags would have been there (and exactly where).
Fix markup html.text.renderEmbeddedHTML.fixMarkup : boolean

This option allows you to fix custom HTML markup, when it is invalid (e.g. <b> tag is open, but never closed), so as not to distort the entire page content after that. When it is true (checked), all custom HTML tags will be parsed and reproduced back along with all closing tags, when they are missed.

In case of HTML markup in XSD annotations, this option has little use since the correctness of embedded XHTML is already enforced by general XML rules. However, it may be important when custom HTML tags are specified by some other means (e.g. see the parameter: Processing | Annotations | Encode markup characters)

Render line breaks html.text.renderLineBreaks : boolean

Specifies whether the newlines ('\n' codes) found in the text must be interpreted with separate lines in the generated output.

On the one hand, you may use newlines in your annotation text just to make it more readable during editing, with no intent to see it broken into the same line in the generated documentation. On the other hand, you may use the original newlines as a simple way of formatting of your text.

When this option is true (checked), all '\n' codes will be rendered with the new lines in HTML (i.e. replaced with <br> tags).

When this option is false (unchecked), all '\n' codes will be passed to the output as is.

RTF Options

When in Generator Dialog you select RTF output format and click «Options» button, you will see the following RTF Option Inspector dialog (click on the screenshot to see the corresponding option description):

The descriptions of RTF options (the default option values are underlined):

Option Name / Type / Description
Styles The group of options related to RTF styles
Include paragraph styles
Include character styles 		rtf.styles.include.parStyles : boolean
rtf.styles.include.charStyles : boolean

These two options specify whether paragraph/character styles should be included in the generated RTF.

When the option is selected, for each style defined in templates a corresponding RTF style will be generated and references to it will be inserted in every location where that style is used.

When the option is unselected, no specific style information will get into the RTF. However, any formatting specified in the template styles will be used anyway.

You may need to disable the inclusion of style information in some situations, when the generated RTF is intended primarily for using in non MS Word applications. Certain RTF readers, although appear to understand most of the RTF settings quite well, nevertheless, may produce such a mess with the styles imported from an RTF that the result document may look considerably distorted.

Here are the option values recommended for different destination applications:

Open with Option value
MS Word true
OpenOffice.org false
Attached Template rtf.styles.attachedTemplate : file pathname

This option allows you to attach your MS Word document template (.dot file) to the generated RTF document. This template may override the formatting styles originally specified in FlexDoc templates.

MS Word uses the styles contained in dot-files to dynamically replace the formatting of equally named styles contained in RTF documents. The styles are connected by their full names.

For example, let's assume that in your dot-file you have a paragraph style called “My Cool Style” which you want to use in your docs.

Then, you will need to define a paragraph style in the template exactly with that very name “My Cool Style”. To define a style in the Template Designer, you should go to «File | Styles» menu item which invokes the Formatting Styles dialog.

Once you have defined “My Cool Style” paragraph style in your template, you may or may not specify in that style some formatting properties as you like (which actually doesn't matter as you wish to override them with the dot-file).

Then, you should assign that style to specific template components whose output you want to format using the dot-file.

In particular, you should specify the «Style» setting in the component's Properties Dialog → Formatting → Paragraph (or Text) tabs. Note, that other formatting settings in those tabs should be specified as 'default'. In accordance to RTF rules, the local formatting settings different from those defined in the template styles will have the higher priority over the styles and, therefore, will not be overridden by dot-files.

Note: This setting will work only when “Include styles” options are selected.

Text The group of options to control the processing of text (character data) supposed for printing in the output.
Render embedded HTML rtf.text.renderEmbeddedHTML : boolean

Specifies whether to render (interpret) embedded HTML markup.

Embedded HTML markup are HTML tags found in the plain text supposed for printing in the output. Such text typically comes directly from the data source (e.g. doc-comments or annotations). However, it may be specified in templates as well. Rendering of that HTML markup means adding the formatting encoded with it to the primary formatting specified in templates.

When this option is true (checked), all custom HTML tags will be parsed and rendered with the appropriate features of RTF. That's pretty much complicated processing and only limited set of HTML tags is supported in this way (see Which HTML tags can be used?). Any other tags will be ignored.

When this option is false (unchecked), all custom HTML tags will be converted to ordinary text and printed in the output. So, you will be able to see what your HTML tags would have been there (and exactly where).

Render line breaks rtf.text.renderLineBreaks : boolean

Specifies whether the newlines ('\n' codes) found in the text must be interpreted with separate lines in the generated output.

On the one hand, you may use newlines in your annotation text just to make it more readable during editing, with no intent to see it broken into the same line in the generated documentation. On the other hand, you may use the original newlines as a simple way of formatting of your text.

When this option is true (checked), all '\n' codes will be rendered with the new line in RTF (i.e. \line controls).

When this option is false (unchecked), all '\n' codes will be passed to the output as is.
Hypertext The group of options controlling the generation of hyperlinks and bookmarks
Generate hyperlinks rtf.hypertext.hlinks : boolean

Specify whether to add hyperlinks in the RTF output.

Hyperlinks will be highlighted with a special style specified for hyperlinks in templates (typically, blue text with underlining).

Note: To have cross-reference hyperlinks (those pointing within the same document) to be generated, the “Generate bookmarks” option must also be selected. Without it, only external (URL) hyperlinks will be possible.

Generate bookmarks rtf.hypertext.bookmarks : boolean

Specify whether to add bookmarks in the RTF output.

Bookmarks are needed to generate both cross-reference hyperlinks and page number references.

Bookmark name prefix rtf.hypertext.bookmarks.prefix : string

Specify prefix for automatically generated bookmark names.

When the name of a bookmark is generated automatically, it is made of some prefix (the same for the whole RTF document) and an internal bookmark number (about which it is certain only that it is unique within that document). For example, if the prefix is "abc", the automatic bookmark name may look like:

abc125
where '125' is the bookmark number.

The default bookmark name prefix is "b". With this option, you can specify a different prefix to be used in the RTF document you will generate.

When you need to merge several RTF files produced with FlexDoc into a single document, you should generate those files with different bookmark prefixes. This will ensure that the bookmarks from different RTFs never overlap and all hyperlinks and page number references in the result document are correct.

Note: The generation of the bookmarks is specified in templates in "Hypertext" properties of particular template components. In those properties, it is also possible to assign a formula expression that will generate specific bookmark names. The bookmark names produced by such formulas will never be changed (no additional prefix will be added to them). The prefix is used only when a bookmark name is produced completely automatically by the generator (without any programming about it in the template).

Tables The group of options controlling the generation of tables in RTF
Allow auto resize table cells rtf.tables.allowAutoFit : boolean

Allows automatically resize table cells to fit contents.

When this option is selected (true), the table autofit setting is added to the definitions of tables in RTF. (Note that this will affect only those table generated by the template components with the specified «Formatting | Table | Auto resize to fit contents» setting).

In Microsoft Word, that RTF setting will activate the “Automatically resize to fit contents” option for the given table.

You may want to disable the table autofit for some reasons. For instance, some RTF readers do not interpret it (e.g. OpenOffice.org) or even in MS Word there is a problem with wrapping of long nonbreaking strings within tables with autofit.

Break long nonbreaking strings rtf.tables.breakLongStrings : boolean

Specify whether to break automatically the long nonbreaking strings placed within the tables with the table autofit setting (see option: Tables | Allow auto resize table cells).

This option addresses a problem with wrapping of very long nonbreaking strings within table cells. Some of your data may be represented in the generated documentation by long strings without spaces. For instance, this may be very long qualified names of Java classes, some character patterns and so on. MS Word interprets such strings as single nonbreaking words. (This happens also when all spaces in a string are nonbreaking.)

The problem arises when nonbreaking strings are placed in table cells. Many FlexDoc templates use tables as layouts, so lots of text data are put in table cells. To have a table-based layout to be arranged correctly, the table autofit RTF setting is specified with those tables. MS Word normally arranges such tables correctly and wraps the text as needed. But this works well only when the text consists of not too long words separated with spaces. When there are long sequences of characters without spaces, MS Word does not wrap them. Instead, it produces a table so wide that it is "displayed" beyond the page, making some data invisible in the result document.

Unfortunately, we have found no reliable natural way to force MS Word to wrap long nonbreaking strings and arrange the table containing them correctly. (That's probably because MS Word is focused mainly to process hand-written documents rather than to layout correctly something generated automatically.)

To work around that problem, the RTF output generator breaks long nonbreaking string automatically by itself according to certain estimations. Because that breaking is not always perfect, a group of options was introduced in order to control it (see nested options).

Never keep rows together rtf.tables.neverKeepRowsTogether : boolean

If you encounter a problem with disappearance of a piece of your text in the generated RTF, this option may help you. Please read the explanation.

When this option is checked (true), each row of a table contained in the generated RTF will always be allowed to break across pages in spite of any settings specified in templates.

Some templates may be designed so that tables generated by them will be specified to keep together on a single page. When such a table does not fit on the rest of the current page, instead of breaking it across pages, the RTF renderer should start this table from the next page.

This works fine until content of each cell in the table is not very large. However, in MS Word, there may be a problem with that. When a text contained in a table cell is so big that it does not fit on a single page, MS Word will not break such a table row automatically regardless of its settings. If the row containing this cell is set to keep on a single page, you simply won't find a piece of your text in the document at all. MS Word will display it beyond the page boundaries!

If you have such a problem, try to check this option and generate your document again. Most likely, you will find the whole your text in the right place after that.

Images The image related options
Store graphics in RTF rtf.images.storeGraphicsInRTF : boolean

Select this option (true), when you want all images to be stored directly in the generated RTF. In that case, the result will be a single file. If unchecked (false), the image files will be saved separately in an 'xxx_files' subdirectory near the document. Only references to them will be inserted in the generated RTF output. This may reduce the result file size, particularly when some big images are repeating.

See also: How to insert images using HTML markup?
Show failed image paths rtf.images.showFailedPaths : boolean

When an image specified by a pathname (or URL) is not found or cannot be loaded, it is replaced with a placeholder (i.e. a special icon indicating the image failure).

When this option is selected (true), in addition to the placeholders, the failed image's pathnames (or URLs) will be shown in the generated RTF, so you could see where the generator tried to find those images.

Note, since the file pathnames tend to be long nonbreaking strings, appearing them in the generated document may considerably distort its formatting layout. That's why this option was introduced and unselected (false) by default.

Allow image rotation rtf.images.allowRotation : boolean

Allows rotating big images to make them better fit in the specified paper size in order to minimize the image scaling. Currently, this is supported only for the element images (diagrams) generated in PNG or GIF format and only when all graphics is stored in the RTF file (see option: Store graphics in RTF).

Note: The rotation should also be enabled in the template Image Controls generating those images.

Other options Miscellaneous options
Tune output for MS Word rtf.misc.tuneForMSWord : boolean

When this option is true, the generator will adjust some RTF formatting settings specifically for MS Word.

Although Microsoft is the originator of RTF format, the MS Word itself appears to have some oddities of rendering certain RTF settings, even though those settings may well follow the RTF specification. For instance, when displaying the paragraph or table borders, their horizontal positions may be shifted (e.g. when MS Word interprets horizontal margins of a paragraph, it draws the paragraph borders and paddings within the specified margin space but not within the paragraph content as it might be natural).

To overcome this, in such cases, we adjust the initial dimensions in the opposite way so as the result formatting would look properly in MS Word (e.g. to make the actual paragraph margin look as intended the margin width specified in RTF is increased by the paragraph border and padding widths).

However, when you generate RTF to display it primarily not in MS Word but rather in different viewers or editors (e.g. OpenOffice.org under Linux), which interpret the original RTF specification more literally, those specific adjustments may cause a visible distortion of the intended formatting of the result document. In such cases, we recommend to uncheck this option.

Values of this option recommended for different destination applications:

Open with Option value
MS Word true
OpenOffice.org false
Suppress timestamp rtf.misc.noTimeStamp : boolean

Specifies whether to suppress the date/time information included in a special comment inserted automatically at the beginning of every generated RTF file, which looks as the following:

{\comment Generated by FlexDoc/XML 1.12 on Mon Feb 12 20:57:43 CET 2018}
When this option is selected (true), such a comment is still inserted, however without the current date/time:
{\comment Generated by FlexDoc/XML 1.12}

How to specify a schema file pathname with spaces?

When some of your XML schema file pathnames contain spaces, to specify them to the generator, you need to enclose every such a pathname in double quotes. For example:
"c:\My XML Projects\schemas\products.xsd"
This should be done both in the Generator Dialog and on the generator command line.

How to specify multiple input XML schemas?

You can easily generate a single (common) XML schema documentation by any number of different XML schema files. At that, when a component from a schema A is used somewhere in a schema B, this will be mentioned and reflected with cross-hyperlinks in the corresponding sections of the documentation parts generated by both schemas.

Let's suppose, we have an XML schema called “Products.xsd”, which contains the following definition: 

<xs:element name="ProductId" type="xs:integer"/>
Now, we want to generate the documentation for that schema and integrate it together with the documentation generated for the “XML Schema for XML Schemas”, which is the schema (found at www.w3.org/2001/XMLSchema.xsd) that defines the W3C XML Schema language itself.

To do this, in the “XML File(s)” field of the Generator Dialog, we should specify the following line:

Products.xsd http://www.w3.org/2001/XMLSchema.xsd
or the following:
"Products.xsd" "http://www.w3.org/2001/XMLSchema.xsd"
which is the same.

After finishing of the generation, we will receive a documentation containing the full details of both “Products.xsd” and “XMLSchema.xsd” schemas. In addition, every type that is defined in “XMLSchema.xsd” and used in “Products.xsd” will be hyperlinked to its «Component Documentation» generated by “XMLSchema.xsd”. For example: 

<xs:element name="ProductId" type="xs:integer"/>
Moreover, in that case, the «Usage Locations Report» of the "xs:integer" type will also contain mentioning of the "ProductId" element, which is defined in “Products.xsd” schema and uses this type.

I have too many input schemas. How to specify all of them?

Instead of a single file pathname, you should use a pathname pattern, e.g.:
c:\schemas\**\*.xsd
You can also combine any number of such patterns in the same input file specification, e.g.:
"c:\My XML Projects\schemas\*.xsd" c:\schemas\**\*.xsd
That will work both in the Generator GUI and on the command line.

For more details, please see: FlexDoc/XML | Documentation | Running Generator | Tips | Input XML Files | Using file pathname patterns.

How to switch between different generator configurations?

You need to generate different types of documentation controlled by lots of different settings (templates, parameters, etc.) and you want to easily switch between them. Here is how you can easily achieve that.

Note that the entire Generator GUI is basically the editor of generator.config file and the generator launcher. By default generator.config is stored at:

{flexdoc-xml}/config/generator.config
But nothing prevents you to use as many different generator.config files as you want. The one, which is actually used at a particular moment, can be specified with the -config command line option.

Let's suppose you want to generate two different types of documentation: A and B.

To prepare the generation of documentation type A

Make a copy of the default generator.config like this:
{flexdoc-xml}\config\generator_A.config
Make a copy of the default generator.bat:
{flexdoc-xml}\bin\generator_A.bat
Open generator_A.bat with some text editor and change the last line like this (with the red is highlighted what you need to add):
"%JAVA_HOME%\bin\java" %JAVA_OPTIONS% -cp "%CLASS_PATH%" xyz.flexdoc.xml.Generator -config "%FDH%\config\generator_A.config"
Save it. Now you can run generator_A.bat each time you want to generate documentation of type A. All settings you specify during that will be saved in generator_A.config.

To prepare the generation of documentation type B

Do the same as for type A, but instead of 'A' use 'B' in all those file names.