Part IV
Advanced Usage of TeX4ht

12  The TeX4ht Packages
     12.1  The no-package approach
     12.2  Providing options to the post-processors
13  Configuring TeX4ht’s HTML
     13.1  Summary
     13.2  myconfig.cfg
     13.3  myconfig.cfx
     13.4  Adding additional global options
     13.5  Document-level configuration
14  Pictures
     14.1  Summary
     14.2  Pictures in standard SWP documents
     14.3  Pictures in Portable LaTeX documents
     14.4   Maple / MuPad pictures
     14.5  .wmf pictures
     14.6  Changing the image extension
15  Hypertext Links
     15.1  Stand-alone SWP support
16  Mouseover
17  Miscellaneous Tips
18  Other translations
     18.1  Configuration files for alternative translations

12 The TeX4ht Packages

TeX4ht uses a package, tex4ht.sty (or for SWP users, swpht.sty, which loads tex4ht.sty), to redefine most of the TeX/LaTeX language into constructs which the post-processors, tex4ht.exe and t4ht.exe, can use to transform your document into HTML. Options to the packages allow you to customize the kind of HTML you produce — for example satisfying the current standard (HTML 4.0) or the earlier HTML 3.2. So when you wish to convert your source document to HTML, you must ensure that the TrueTeX compiler loads the package and sees your options. There are two ways to do this.

The no-package approach
You can omit any reference to an explicit package in your source document, and let the batch files supply the details for you. In this case your source document can be used without alteration to produce both HTML (via a batch file) and typeset output (via the TrueTeX previewer). This method is new with TeX4ht/SWP Version 2, and for most users will be the preferred strategy. The downside here is that any package options you would like to include have to come from somewhere: we provide — and allow you to reconfigure — a default set of options; but if you want something special you will have to provide them yourself on the command line, and this is somewhat clumsy. However, in most cases the no-package approach is the preferred approach.

The explicit-package approach
You can explicitly include a reference to the package in your source document, complete with options. This was the only way available in TeX4ht/SWP Version 1, and is still useful, for example when a document contains an unusual set of options, for example, to break your document into HTML sections. The downside is that the package needs to be turned on or off, according as you want to produce HTML or ordinary typeset LaTeX. For most new users, this is probably not the approach you will select. Because this approach is not generally recommended, the details are provided only in Appendix C.

12.1 The no-package approach

Until recently, the only way to produce HTML with TeX4ht was by including the package explicitly. But Eitan Gurari has now provided an alternative, which is fully supported under SWP. With this approach you do not have to add a package statement to your source: instead, the batch file htlatexss.bat provides the necessary interface. The advantage is that you can produce typeset output and HTML output from a single source, without having to make any changes whatsoever. The disadvantage is that it is a bit more difficult to customize package options.

To produce HTML from an SWP document myfile.tex which does not include an explicit reference to the swpht package:

12.1.1 Providing options

If your document contains no explicit TeX4ht package, the system still needs to get its options information from somewhere, and in this case you must provide them, either via a default setting, or explicitly on the command line.

To provide options on the command line, you include them in a double-quoted comma-separated list immediately following the number of LaTeX passes you need. Note that in this case you must provide the number of passes explicitly: you cannot rely on the default. Options may be entered in any order, with one exception: if you want the system to use a personal configuration file, its name must come first in the list; otherwise, the first option must be one of html, or htm.

Here are some examples: we use the htrun program to start TeX4ht and process the file mytest.tex, but the syntax is the same if you call htlatexss.bat directly.

12.2 Providing options to the post-processors

The TeX4ht system uses the TrueTeX compiler to translate LaTeX, and then finishes the job by way of two post-processors, tex4ht.exe and t4ht.exe. It is possible to pass additional options to the post-processors, too; but the only way to do so is on the command line.

Most of the time you will not need to do this. But there are two options which may be useful.

The first allows you to move or copy your output to a new location (for example, to your web site, if it is accessible that way). You do so by specifying a -d argument to the t4ht.exe post-processor, which is the fifth command-line option. Note that if you do this, you must explicitly specify the desired number of LaTeX passes, and provide empty place-holders for any other unused arguments: the place-holders are indicated via a pair of double-quotes.

For example, the following command line:

htrun mytest 1  ""  ""  "-dh:/myarea/papers/"


How the transfer is handled depends on the M and C entries in tex4htx.env: as distributed, the hypertext files (.html, .css) will be copied to the new location (the C script specifies copy) while the .gif files will be moved there, and will consequently no longer be present in the current directory (the M script specifies move). However, this is probably not the preferred setup. Unlike Unix, the DOS move command will move a file only if it does not already exist in the destination. So the next time your process your source file, the gifs will not be updated in the destination directory. To get around this, edit c:\tex4ht\tex4htx.env and, in the M script line, change move to copy.

The second option is useful if your document has lots of multi-character or equation graphics. Normally, these will be re-generated each time you process your source document; and this can take time.  If you are sure that nothing has changed — for example, you’ve just corrected a typo in the source — you can prevent the graphics being re-made by using the -p option to the t4ht post-processor. (It’s important to be careful here: the equation graphics are sequentially numbered, so if you “just” insert a  new one somewhere, this will not count as “nothing changed”). The following two command lines do this; the second combines the no-graphics-remake option with the transfer option described above.

htrun mytest 1   ""  ""  "-p"

htrun mytest 1   ""  ""  "-dh:/myarea/papers/ -p"

13 Configuring TeX4ht’s HTML

This section describes how you can instruct TeX4ht to alter the HTML it produces. Note that these changes will not affect the appearance of your typeset output.

13.1 Summary

In order to change the way TeX4ht/SWP translates LaTeX into HTML you use one or more configuration files. In the explicit-package approach, you will usually find that any required files are automatically used. See Appendix C for the no-package approach.

Standard SWP LaTeX
Use of configuration files is optional. The system as distributed automatically makes use of the bare-bones configuration file myconfig.cfg, described in section 13.2.

Portable LaTeX
A configuration file is required in order to correctly process pictures in Portable LaTeX documents. As distributed, the system automatically makes use of myconfig.cfg to obtain the necessary support. See section 13.2.

A configuration file is needed only if you wish to make use of automatic picture handling, as described in section 14.3, or document-specific configuration files. As distributed, TeX4ht/SWP will use myconfig.cfg to obtain that support. See section 13.2.

Plain-TeX, TeXinfo
Default configuration files are not supported. If needed, they may be included as command-line package options.

Note that the same configuration file can be used for both standard SWP documents and for Portable-LaTeX and non-SWP-LaTeX documents, because of conditional code in the file.

Configuration files and command-line package options Automatic inclusion of myconfig.cfg is implemented via the environment variable swpht, set in the batch files. If you provide your own package options from the command line, this has the effect of over-riding the defaults. This means that if you provide a set of command-line package options, you will obtain the facilities of myconfig.cfg only if you explicitly include it in your options. Moreover, it must come first in the list.

A side-effect of using the configuration file myconfig.cfg is that you will not be able to process a .tex file with the same base name (in the default case, a file called myconfig.tex ): the system will get confused.

13.2 myconfig.cfg

TeX4ht includes myconfig.cfg as a bare-bones example of a configuration file. As distributed, it merely provides for the possibility of document-specific configuration files (see below, section13.5), and for the correct handling of pictures in Portable LaTeX documents. This file is automatically included in the default options set by the batch files, via the environment variable swpht.

13.3 myconfig.cfx

I also include a second file, myconfig.cfx, which adds the following features:

  1. The TeX sans-serif font will be rendered in Arial (or Helvetica, or Lucida Sans, depending on what is available on the reader’s platform). This overrides the default TeX4ht HTML 4, configuration, which does nothing — ie renders it in the browser’s default proportional font.
  2. The TeX slanted font will be rendered in purple italics. This overrides the default TeX4ht configuration, which in HTML 3.2 may use the default proportional font.
  3. It reconfigures the LaTeX description list to make the labels come out bold: as far as I can tell, the default setup doesn’t do this correctly in HTML 3.2.

Given the reliance of the system on the specific file myconfig.cfg, the simplest way to use myconfig.cfx is to copy any wanted customizations to myconfig.cfg. Alternatively, if you use the explicit command-line specification of package options, you can just include myconfig.cfx in the list, since in that case no configuration file is used by default. You can also place any of these customizations in a document-specific configuration file; but of course in this case they will not be globally available.

If you don’t like the choices in myconfig.cfx you can change them: you may want for example to remove the “purple” attribute for slanted fonts, though if you do so there will be no distinction between slanted and italics, as there is in the Computer Modern fonts.

13.4 Adding additional global options

If you want a TeX4ht option (for example, to produce HTML-3.2 output) as your default you can add it as follows:

If you do not find a set swpht statement, this means that default configuration parameters are not supported for this TeX/LaTeX file. For example, they are not supported for plain-TeX translation, via the batch file httexs.bat. However, you can always provide options via the command line.

Finally, remember that, as explained above, command line package options override defaults. Thus, if you wish to obtain your default options when you also provide command-line options, you must repeat the defaults there.

13.5 Document-level configuration

It is also possible to have additional configuration files which apply only to the document being processed by the system (or, more specifically, if your document contains subdocuments, to the top-level document). This feature is not part of Eitan Gurari’s TeX4ht distribution. If things start to go inexplicably wrong, you should try removing this feature before attempting further diagnosis. This feature is only available if you are using a global configuration file, like myconfig.cfg, which enables it.  

Under this setup, if you are processing myfile.tex and are using myconfig.cfg, the system will also look for

To add new processing instructions, just type them into the appropriate document-level configuration files in the same directory as your source (.tex) file. You should not repeat either the \Preamble and \begin{document} commands, since these are supplied in myconfig.cfg.

To disable document-level configuration while continuing to use myconfig.cfg:

14 Pictures

I use “picture” to refer to those graphics you insert into your document with the File -> Import Picture dialog in SWP, or that are generated by the computer algebra engines. SWP has always been known for the variety of picture types it supports, and Version 2 of the TeX4ht/SWP provides substantially enhanced picture handling. First, it can now deal with floating and boxed pictures, to the extent that they are handled by TeX4ht. (In Version 1 these properties were simply ignored). Second, while the default picture support simply writes an appropriate IMG tag into your HTML file leaving it up to you to produce the Web images, we also support automatic conversion for some picture types, and you can easily add additional automatic converters as you obtain them. (This picture support is distinct from the support offered by TeX4ht for conversion of mathematical symbols and equations to Web images).

14.1 Summary

The way you use the TeX4ht/SWP picture support depends on the document type. In the following descriptions, “default picture support” refers to the system’s just writing the proper IMG tag into your HTML document, without any attempt to generate the Web image itself:

Standard SWP
Default picture support for standard SWP documents is built-in to the TeX4ht/SWP system. You do not need to do anything special to invoke it. However, you will need to configure any additional automatic conversions yourself; see section 14.5 and Appendix A.

SWP Portable LaTeX
Default picture support is available only through a configuration file. If you use the no-package approach to conversion (see section C) the system will automatically use the included myconfig.cfg to obtain this support; if you use the explicit-package approach you must include a reference to myconfig in the list of package options (see section 12.1). See section 14.5 and Appendix A for extending the automatic-conversion options.

These appear to TeX4ht/SWP just like Portable LaTeX documents, and picture handling is done in precisely the same way.

plain-TeX, TeXinfo
Picture handling is not supported.

All picture support has the following features/peculiarities:

If these features are a real problem for you, Steve Mayer’s TeXConverter (see section D) provides a way to get around them.

We now discuss the details of picture support in TeX4ht/SWP.

14.2 Pictures in standard SWP documents

The default handling of pictures is to write the appropriate IMG tag into your document and leave it up to you to generate the necessary Web image. But in some cases it is possible to have the system do the conversion for you: of course this depends on your having the necessary conversion tools available. Since you have already installed ImageMagick, you have all you need to convert the following picture types to gifs:

bmp .jpg .pcx .png .tif .wpg .xbm .ico .pbm .pgm .tga .xpm .clp .sgi .dib .eps .ps

and TeX4ht/SWP will automatically generate Web graphics for these types. Appendix A explains how to add (and remove) automatic conversion options. If TeX4ht/SWP does not automatically convert your picture to its Web format you will need to convert it yourself.

Windows MetaFile (.wmf) pictures are special, and section 14.5 discusses how to install automatic conversion support for them.

There is a problem when SWP graphics are used in a document which loads the Babel package (or at least the francais option with Babel). See the Updates section for October 10, 2001 for solutions.

14.3 Pictures in Portable LaTeX documents

Portable LaTeX documents handle pictures via the standard LaTeX \includegraphics macro. But the TrueTeX compiler sets up \includegraphics to generate the precisely same \special command that is generated for standard SWP LaTeX (that’s how you can preview your document even if it is Portable LaTeX), so in effect you’re back to square one. TeX4ht interprets the \special as an instruction to generate a Web image via the normal mechanism, ie dvips + GhostScript + ImageMagick. This fails at the first step, because dvips does not understand the TrueTeX \special, and you will see a series of errors in your DOS session.

So we need to alter the way TeX4ht processes your picture. We cannot do it by adding a LaTeX package because that would destroy portability. The solution adopted here is to use a TeX4ht-specific configuration file. This means that you will not be able to process Portable-LaTeX pictures properly unless you refer to a configuration file.

TeX4ht/SWP will automatically use myconfig.cfg for Portable LaTeX documents which do not explicitly reference the TeX4ht packages, in order to provide default picture support. If your document explicitly loads the TeX4ht/SWP package you will need to include a reference to myconfig.cfg yourself. See section C.3.

It is important to be aware of one side-effect of using a configuration file in the no-package approach: automatic inclusion of myconfig.cfg is via the environment variable swpht in the batch files: if you supply any command-line options to the TeX4ht package — section 12.1.1 — you must always include your configuration file by name because a command line option replaces — and does not augment — the options specified in the environment variable.

As with standard SWP picture support, we implement automatic image generation for these picture types supported by ImageMagick:

bmp .jpg .pcx .png .tif .wpg .xbm .ico .pbm .pgm .tga .xpm .clp .sgi .dib .eps .ps .eps .ps

Appendix A explains how to add (and remove) automatic conversion options. If TeX4ht/SWP does not automatically convert your picture to its web format you will need to convert it yourself.

Windows MetaFile (.wmf) pictures are special, and section 14.5 discusses how to install automatic conversion support for them.

14.4 Maple / MuPad pictures

This section applies to Scientific WorkPlace and Scientific NoteBook documents only. Maple and MuPad pictures are fully supported provided that you have generated the necessary snapshot files. Since snapshots take up disk space, and are needed only for typeset previewing and printing, both programs are installed with automatic snapshot generation turned off, and you will need to turn it on before converting your document to HTML. When you can typeset-preview your document and see all images, you are ready to process it through TeX4ht.

If your standard SWP document has a computer algebra picture for which no snapshot exists, we generate a reference to a non-existent picture file, in this case FRAME-no-graphic, which will receive the default extension in the HTML. If you view the HTML in a browser, this should remind you that you need to generate some snapshots.

For Portable-LaTeX documents, SWP generates an \includegraphics command only if you have produced a snapshot. This means that a missing snapshot will not generate an IMG tag referring to a non-existent graphic. If your HTML document is missing a Maple or MuPad image completely, check that you have generated a snapshot.

14.5 .wmf pictures

Windows MetaFile (.wmf) pictures play a special role in SWP: they are the default format for any computer-algebra pictures, and (in SWP 3.5+) the default format for copy-as-picture operations. The problem is that Unix-based programs like ImageMagick do not support conversion of .wmf pictures to Web images. TeX4ht/SWP optionally supports Irfan-View, an excellent freeware graphics converter which can be run both from the command line and as a GUI. Support for Irfan-View is not enabled by default, because you may wish to implement alternative solutions. Here is how to set up Irfan-View support.

We now change the .wmf picture support for both standard SWP and Portable LaTeX documents. Note that you will always want to change both types, otherwise you could be in for some surprises down the road. We begin with standard SWP support. Open swpht\tcitex\tex\latex\tex4ht\swpframe.sty (where swpht is your top-level SWP directory) in a text editor.

Now for Portable LaTeX. Open swpht\tcitex\tex\latex\tex4ht\portgraf.tex in a text editor. Note that each group contains two \Configure{graphics*} statements, one for lowercase and one for uppercase.

You should now be able to convert .wmf (and .WMF) pictures to Web images automatically.

Note that Irfan-View can convert many other graphics types, so you may want to add additional automatic conversion possibilities. It also appears to be signficantly faster than ImageMagick, so you may want to consider changing the existing automatic conversions, especially if you have many pictures to convert. See Appendix A.1,

14.6 Changing the image extension

You can change the default image extension by putting the following statement into a document-specific .cfh configuration file:


where xxx is your chosen extension. (Note that the description in The LaTeX Web Companion, p. 160, has changed, and is no longer correct). Again, note that this governs only the text of the IMG tag: you still need to generate the graphic yourself. If you are using automatic image generation, you must check that conversion software supports your new image type. If not, you may need to remove automatic conversion facilities — see Appendix A.

15 Hypertext Links

For standard SWP documents, the style file swpht.sty supports the HyperLink dialog, introduced with SWP version 3, in the following way: we generate a live hyperlink whose click-able text is the contents of the “Screen Text” field and whose target is the item pointed to by the “Target” field. Note that the “Left” and “Right” Printed Text items are simply ignored: this makes your HTML look much like the on-screen appearance of your document (the Printed Text fields are designed for paper output rather than hypertext). See Appendix B if you want to change this. The “Target” field handles the characters #, _ and ~ correctly. However, we do not support the backslash (\) as a directory separator in URLs. You must use the forward-slash character (/) for this.

In SWP you can enter a target like mydest, and the effect is to generate a link to a marker within the current document. This form is fully supported in TeX4ht/SWP, provided that the target is a genuine LaTeX label-target, that is, something which is referenced by a counter in the typeset document. Thus, all sectioning and points within numbered lists are appropriate targets, but an SWP Marker in the middle of your text is not, even though the HyperLink movement works correctly in SWP itself. This restriction is a consequence of TeX4ht’s reliance on LaTeX, and the document’s .aux file; Hevea, for example, does not have it. See Appendix B for an inelegant way to get round this if it is important to you.

If you enter a target of mydest.tex, you are clearly intending to generate a link to an external document. Assuming that your target document will eventually also be converted to hypertext, TeX4ht/SWP generates a reference to mydest.html (or .htm if you use that option, or .xml if you’re converting to Mozilla). This applies only to .tex documents — obviously you don’t want your reference to to be treated that way — and only if the reference is of the form filename.extension (so that in a reference containing a drive letter or directory or URL this will not be triggered). If this is a problem for you — if you want mydest.tex to generate a reference to mydest.tex — you can put the following into a document-specific configuration (.cfg or .cfh) file:


Alternatively, if you never want the extension to be changed, you can edit swpht.sty where the macro \PAVTeXExt is first defined. Steve Mayer’s TeXConverter (see Appendix D) implements a more flexible solution, and allows you to decide how to handle these markers on a case-by-case basis.

Icons in the Screen Text field are also supported. The web images corresponding to these are located in \tex4ht\icons and will need to be moved to your source directory. (I am grateful to George Pearson at Mackichan Software for supplying me with the original .bmp images; I used Irfan-View to convert them to .gifs).

We also support a simple “mailto” tag. To create such a tag in your document, use an encapsulated TeX field, called, say “mailto” whose contents are (eg) \mailto{} where of course you will want to include your address, not mine. You can then save it as an SWP Fragment for regular use.

Portable LaTeX documents: the SWP system translates the HyperLink to a standard LaTeX \ref command, surrounded by the “Left” and “Right” printed text (ie to an appearance appropriate to paper). We do not alter this, because re-defining the \ref command could have other undesirable repercussions throughout your document. The mailto tag is not supported, but it is easy to add its definition to a configuration file — just copy the definitions in swpht.sty.

15.1 Stand-alone SWP support

Hypertext support can lead to problems when you run your document through LaTeX in a non-TeX4ht context (ie for regular typesetting). For one thing (in SWP3.0; the problem has been fixed in SWP 3.5) the characters # , _ and ~ are illegal in “Target” fields; for another, the “mailto” macro isn’t known to the system. You can get support in regular typesetting for these characters and “mailto” in two ways:

16 Mouseover

We now support TeX4ht’s mouseover option. This is in the class of Clever Things You Can Do with JavaScript, and requires a JavaScript library, overlib.js, by Erik Bosrup, available from . Everyone who want to use this option needs to get this library: it is not included in either the TeX4ht or SWP distributions. For new users, the rest of the support is built in to the SWP distribution. For existing users, you can set up TeX4ht/SWP support as follows:

  1. You need the *.4ht files dated July 24 2002 or later; if necessary, get them from Eitan’s Bug Fixes page. Place the *.4ht files in SWP’s tex4ht directory, over-writing the existing files.
  2. Place the .exe files in the main TeX4ht directory (typically c:\tex4ht), over-writing the existing files.
  3. Place a copy of the batch file xhtexs.bat into your path. This batch file should already be in the update subdirectory of your tex4ht directory, and it should be correct for your installation.
  4. If your installation of the support is earlier than this date, retrieve an updated version of swpht.sty in here and replace the existing version.

17 Miscellaneous Tips

This section collects miscellaneous solutions by users. If you have something you’d like to see included, send it in!

Inline math TeX4ht sets inline math via a combination of characters from the default font where possible and images where necessary. (Note that display math is always wholly pictures). Some users object to the way things line up in this situation. You can convert all inline math to picture format by putting the following commands in a configuration file:

\Configure{PicMath}{}{}{}{class=’’math’’; align=’’absmiddle’’}  

Note that, unless you want to make extensive use of TeX fields, there’s no way to do this selectively, so you may find yourself faced with a large increase in the number of images the program generates. (Source: Eitan Gurari and Doyle Cutler).

Turning off image generation If you just want to regenerate the HTML, knowing that all images — if any — are already present and in the correct order (for example, you’ve just corrected a simple typo somewhere), you can do this via

htrun myfile n ’’ ’’   ’’ ’’   ’’-p’’  

where as always, n is the number of LaTeX passes. But be careful — if you add anything which would require that a non-glyph gif be generated, chances are your equations will be out of order.

Appearance of the TOC If you’d like the TOC to be displayed with a bit of space between the major entries, and with sub-entries indented (as in the present document) you can insert the following code into a configuration file:


18 Other translations

TeX4ht is an extremely flexible system, and supports translation of TeX and LaTeX to a variety of other output formats beyond HTML. When you installed the SWP support, you also configured the batch files needed to enable the following translations:

However, because browser support for these is relatively limited, the installation routine did not move the batch files into your path (to avoid cluttering up that directory) but left them in the c:\tex4ht\alt-trans. All you need to do is move them into your path. The batch files have the following prefixes:

Output type Prefix

XHTML+bitmap math    xh
XHTML+MathML xhm
XHTML+MathML on Mozilla   mz

So that, to enable (say) Mozilla support, you should go to c:\tex4ht\alt-trans and say copy mz*.bat to a directory in your path.

Important: if you are using Steve Mayer’s TeXConverter (see Appendix D), all the batch files (for HTML as well as for any alternative translations) must be in the same directory.

The simplest way to use the new support from a DOS session is via htrun: all you need to do is supply the Prefix shown in the table above to the command line, before the name of the source document. So, for example, to translate mydoc.tex to Mozilla (this generates an .xml file) you’d say

htrun -mz myfile 3

(where the 3 requests 3 passes of the TrueTeX compiler). The only difference between this and other examples of htrun is the switch -mz; note that you can explicitly request HTML translation using the -ht switch (which is the default if no switch is provided). The effect of the switch is that the “bare” name of the batch file listed in htrun.ini has the switch prepended; so if, for example, the relevant batch file is latexp.bat (in htrun.ini) and you use the switch -xyz on the htrun command line, the program tries to run xyzlatexp.bat. In principle, this makes it possible to provide your own special handling for translations: you provide a series of batch files, and call htrun with the new prefix.

There is one consideration to bear in mind. Suppose you’re using the package form of TeX4ht with the html option specified — that is, your source file contains a line like


You can certainly process your file with an alternative-translation switch but you will still get HTML output (because that’s what the package options request). If you are seriously interested in alternative formats, clearly the no-package form of your source document is the one to use. Steve Mayer’s TeXConverter (see Appendix D) provides an nice alternative solution: if you request an output format with the “wrong” package options, the Converter will offer to (temporarily) remove the entire package line for you. Your file will then be processed by a batch file which does not expect an explicit package, and all will be well.

Finally, note that Eitan Gurari is regularly adding new translation types to the system: I have included here only the ones most likely to interest SWP users, but if there is a demand for others it should take only a few minutes to set up a series of batch files for them. (Eitan is adhering to the Prefix notation of htrun). So let me know. Here is a link to the current list of what’s available.

18.1 Configuration files for alternative translations

If you have established a “global“ configuration file for HTML translation, you will probably not be able to use it with the alternative translation schemes, especially if it contains instructions to write “plain” HTML. To allow you to use the configuration mechanism, we provide three “bare-bones” configuration files, one for each translation type, as follows (these were copied to your LaTeX tree when the TeX4ht/SWP system was installed):

Output type Configuration File

XHTML+bitmap math    myconfig-xh.cfg
XHTML+MathML myconfig-xhm.cfg
XHTML+MathML on Mozilla   myconfig-mz.cfg

As distributed, these files do nothing except establish a framework for document-specific configuration files: when you are translating mydoc.tex, they look for, and, if found, read, configuration files named mydoc-x.cfg and mydoc-x.cfh, where x is xh, xhm, or mz, depending on the type of translation being done. These files play the same role as the document-specific configuration files mydoc.cfg and mydoc.cfh, described in section 13.