The workflow consists in preparing a LaTeX document, running LaTeX, and then generating various intermediary and final formats in order to meet the needs of the caller.
We shall give a name to each of these steps corresponding to what data format they generate. These names will be useful later when discussing user scripts.
All commands are executed within a temporary directory unique to the current job.
Assuming no user script is being used, the workflow goes as follows.
Prepare the LaTeX document. The document is prepared using a standard, fixed
template (when using the KLatexFormula application; if you’re using
libklfbackend directly you can change this). The template basically wraps
the formula in an article documentclass LaTeX document with the given
preamble, a minimal body, along with some commands to set the colors right.
Generated format: latex.
Run latex to get DVI output. Basically, we just run
latex filename.tex.
Generated format: dvi, requires latex.
Run dvips to get “raw” EPS output.
Generated format name: eps-raw, requires dvi.
We obtain the bounding box information. If settings.calcEpsBoundingBox is
set, then we run gs in a special mode such that it reports the actual
bounding box of the graphics (and not simply the reported one). If
settings.calcEpsBoundingBox is not set, then we simply read out the
reported bounding box in the raw EPS file.
We then sanitize the EPS file (including normalizing the coordinate system as
well as some other small tweaks; for details see the source code). Any
requested vector scaling is applied here. If settings.calcEpsBoundingBox
was set, this new EPS file honors the calculated precise bounding box.
Generated format name: eps-bbox, requires eps-raw.
Additional processing of the EPS file via gs to outline fonts, if
settings.outlinefonts is set. If settings.outlinefonts is not set, gs
is not run and this new EPS file is a copy of the eps-bbox one.
Generated format name: eps-processed, requires eps-bbox.
Generate PNG data by calling gs. Meta-information fields are added
separately after the gs call.
Generated format name: png, requires eps-processed.
Generate PDF (only if requested) by calling gs again. Meta-information
added via pdfmarks.
Generated format name: pdf, requires eps-processed.
Generate SVG (only if requested and only if available via gs). Run gs to
obtain the svg output (note that not all versions/distributions of gs
provide this experimental driver). Furthermore, we fix the reported graphics
size manually from gs’s inaccurate output.
Generated format name: svg, requires eps-processed.
A backend engine user scripts allows to override the steps described above.
If a “klf-backend-engine” user script is to be used, then Point 1 is carried out, generating the LaTeX template, and then immediately the user script is executed directly instead of going on to Point 2.
The user script, via its scriptinfo.xml meta-information, reports which
formats it is capable of generating, as well as which other formats shouldn’t be
generated at all (skipped formats). After running the user script, we determine
which other formats can be generated which the user script hasn’t already
generated and which aren’t to be skipped. The steps corresponding to those
formats, based on the formats provided by the user script, are executed.
See also:
The latex workflow is the work of the klfbackend library. Basically,
everything is concentrated in the KLFBackend::getLatexFormula() function.
Check out also the API.