Skip to main content
\( \newcommand{\lt}{<} \newcommand{\gt}{>} \newcommand{\amp}{&} \)

Section4.4Customizations, String Parameters

There are some aspects of your output that are entirely divorced from the actual content, and are presumably all about how that content is presented. Two good examples are the size of the font used in /PDF/print output, and the granularity of web pages in HTML output (by this we mean, is each web page a whole chapter, a whole section, a whole subsection?). Producing output with varying values of these parameters does absolutely nothing to change your content in any way, and so should not be a part of your source. Thus we provide values for these parameters on the command-line at processing time. They have become known as stringparam for a soon-to-be obvious reason.

Suppose you want to make a large-font version of your textbook for a student who has limited vision. Look inside the top of xsl/mathbook-latex.xsl and find the latex.font.size parameter. The preceding comments in this file suggest 20pt is the maximum supported. So you would use a command-line like the following (possibly with --xinclude, etc.).

$ xsltproc --stringparam latex.font.size "20pt"
/path/to/xsl/mathbook-latex.xsl ~/books/aota/animals.xml

You can use as many stringparam as you like on the command-line (or in your scripts). The quotation marks are not strictly needed in this example, but if the value of the parameter has spaces, slashes, etc., then you need to quote-protect the string from the command-line processor, and either single or double quotes will work (and protect the other kind).

These parameters are documented in the XSL files themselves, principally -common, -latex and -html, and occur near the top. They assume sensible defaults for beginners, and error-checking is careful and robust. They will be easier to locate and use when we have the time to document them more carefully here in the Author's Guide.

One caveat for using these is that experience has taught us that some of the parameters we created early on really do affect your content. We will change some of these, but always provide a smooth upgrade path through deprecations, with little or no disruption to your workflow.