Next: ToDo, Previous: Known problems, Up: top [Contents][Index]
This package consists of two parts: a LaTeX style that splits the output into appropriate parts with one preview object on each page, and an Emacs-lisp part integrating the thing into Emacs (aided by AUCTeX).
• The LaTeX style file | ||
• The Emacs interface | ||
• The preview images | ||
• Misplaced previews |
Next: The Emacs interface, Previous: For advanced users, Up: For advanced users [Contents][Index]
The main purpose of this package is the extraction of certain environments (most notably displayed formulas) from LaTeX sources as graphics. This works with DVI files postprocessed by either Dvips and Ghostscript or dvipng, but it also works when you are using PDFTeX for generating PDF files (usually also postprocessed by Ghostscript).
Current uses of the package include the preview-latex package for WYSIWYG functionality in the AUCTeX editing environment, generation of previews in LyX, as part of the operation of the pst-pdf package, the tbook XML system and some other tools.
Producing EPS files with Dvips and its derivatives using the
-E option is not a good alternative: People make do by
fiddling around with \thispagestyle{empty}
and hoping for the best
(namely, that the specified contents will indeed fit on single
pages), and then trying to guess the baseline of the resulting code
and stuff, but this is at best dissatisfactory. The preview package
provides an easy way to ensure that exactly one page per request
gets shipped, with a well-defined baseline and no page decorations.
While you still can use the preview package with the ‘classic’
dvips -E -i
invocation, there are better ways available that don’t rely on Dvips not getting confused by PostScript specials.
For most applications, you’ll want to make use of the tightpage
option. This will embed the page dimensions into the PostScript or
PDF code, obliterating the need to use the -E -i
options to Dvips.
You can then produce all image files with a single run of
Ghostscript from a single PDF or PostScript (as opposed to EPS)
file.
Various options exist that will pass TeX dimensions and other information about the respective shipped out material (including descender size) into the log file, where external applications might make use of it.
The possibility for generating a whole set of graphics with a single run of Ghostscript (whether from LaTeX or PDFLaTeX) increases both speed and robustness of applications. It is also feasible to use dvipng on a DVI file with the options
-picky -noghostscript
to omit generating any image file that requires Ghostscript, then let a script generate all missing files using Dvips/Ghostscript. This will usually speed up the process significantly.
• Package options | ||
• Provided commands |
Next: Provided commands, Previous: The LaTeX style file, Up: The LaTeX style file [Contents][Index]
The package is included with the customary
\usepackage[options]{preview}
You should usually load this package as the last one, since it redefines several things that other packages may also provide.
The following options are available:
active
is the most essential option. If this option is not
specified, the preview
package will be inactive and the document
will be typeset as if the preview
package were not loaded,
except that all declarations and environments defined by the
package are still legal but have no effect. This allows defining
previewing characteristics in your document, and only activating
them by calling LaTeX as
latex '\PassOptionsToPackage{active}{preview} \input{filename}'
noconfig
Usually the file prdefault.cfg gets loaded
whenever the preview
package gets activated. prdefault.cfg is
supposed to contain definitions that can cater for otherwise bad
results, for example, if a certain document class would otherwise
lead to trouble. It also can be used to override any settings
made in this package, since it is loaded at the very end of it.
In addition, there may be configuration files specific for certain
preview
options like auctex
which have more immediate needs.
The noconfig
option suppresses loading of those option files,
too.
psfixbb
Dvips determines the bounding boxes from the
material in the DVI file it understands. Lots of PostScript
specials are not part of that. Since the TeX boxes do not make
it into the DVI file, but merely characters, rules and specials
do, Dvips might include far too small areas. The option psfixbb
will include /dev/null as a graphic file in the ultimate upper
left and lower right corner of the previewed box. This will make
Dvips generate an appropriate bounding box.
dvips
If this option is specified as a class option or to other packages, several packages pass things like page size information to Dvips, or cause crop marks or draft messages written on pages. This seriously hampers the usability of previews. If this option is specified, the changes will be undone if possible.
pdftex
If this option is set, PDFTeX is assumed as the
output driver. This mainly affects the tightpage
option.
xetex
If this option is set, XeTeX is assumed as the
output driver. This mainly affects the tightpage
option.
displaymath
will make all displayed math environments subject to preview processing. This will typically be the most desired option.
floats
will make all float objects subject to preview
processing. If you want to be more selective about what floats to
pass through to a preview, you should instead use the
\PreviewSnarfEnvironment
command on the floats you want to
have previewed.
textmath
will make all text math subject to previews.
Since math mode is used throughly inside of LaTeX even for other
purposes, this works by redefining \(
, \)
and $
and the math
environment (apparently some people use
that). Only occurences of these text math delimiters in later
loaded packages and in the main document will thus be affected.
graphics
will subject all \includegraphics
commands
to a preview.
sections
will subject all section headers to a preview.
delayed
will delay all activations and redefinitions the
preview
package makes until \
begin{document}
. The purpose
of this is to cater for documents which should be subjected to the
preview
package without having been prepared for it. You can
process such documents with
latex '\RequirePackage[active,delayed,options]{preview} \input{filename}'
This relaxes the requirement to be loading the preview
package
as last package.
loads a special driver file prdriver.def. The remaining options are implemented through the use of driver files.
auctex
This driver will produce fake error messages at the start and end of every preview environment that enable the Emacs package preview-latex in connection with AUCTeX to pinpoint the exact source location where the previews have originated. Unfortunately, there is no other reliable means of passing the current TeX input position in a line to external programs. In order to make the parsing more robust, this option also switches off quite a few diagnostics that could be misinterpreted.
You should not specify this option manually, since it will only be
needed by automated runs that want to parse the pseudo error
messages. Those runs will then use \PassOptionsToPackage
in
order to effect the desired behaviour. In addition,
prauctex.cfg will get loaded unless inhibited by the noconfig
option. This caters for the most frequently encountered
problematic commands.
showlabels
During the editing process, some people like to
see the label names in their equations, figures and the like. Now
if you are using Emacs for editing, and in particular
preview-latex, I’d strongly recommend that you check out the
RefTeX package which pretty much obliterates the need for this
kind of functionality. If you still want it, standard LaTeX
provides it with the showkeys
package, and there is also the
less encompassing showlabels
package. Unfortunately, since
those go to some pain not to change the page layout and spacing,
they also don’t change preview
’s idea of the TeX dimensions of
the involved boxes. So if you are using preview
for determing
bounding boxes, those packages are mostly useless. The option
showlabels
offers a substitute for them.
tightpage
It is not uncommon to want to use the results of
preview
as graphic images for some other application. One
possibility is to generate a flurry of EPS files with
dvips -E -i -Pwww -o outputfile.000 inputfile
However, in case those are to be processed further into graphic image files by Ghostscript, this process is inefficient since all of those files need to be processed one by one. In addition, it is necessary to extract the bounding box comments from the EPS files and convert them into page dimension parameters for Ghostscript in order to avoid full-page graphics. This is not even possible if you wanted to use Ghostscript in a single run for generating the files from a single PostScript file, since Dvips will in that case leave no bounding box information anywhere.
The solution is to use the tightpage
option. That way a single
command line like
gs -sDEVICE=png16m -dTextAlphaBits=4 -r300 -dGraphicsAlphaBits=4 -dSAFER -q -dNOPAUSE -sOutputFile=outputfile%d.png inputfile.ps
will be able to produce tight graphics from a single PostScript
file generated with Dvips without use of the options
-E -i
, in a single run.
The tightpage
option actually also works when using the pdftex
option and generating PDF files with PDFTeX. The resulting PDF
file has separate page dimensions for every page and can directly
be converted with one run of Ghostscript into image files.
If neither dvips
or pdftex
have been specified, the
corresponding option will get autodetected and invoked.
If you need this in a batch environment where you don’t want to
use preview
’s automatic extraction facilities, no problem: just
don’t use any of the extraction options, and wrap everything to be
previewed into preview
environments. This is how LyX does its
math previews.
If the pages under the tightpage
option are just too tight, you
can adjust by setting the length \PreviewBorder
to a different
value by using \setlength
. The default value is
0.50001bp, which is half of a usual PostScript point, rounded
up. If you go below this value, the resulting page size may drop
below 1bp
, and Ghostscript does not seem to like that. If you
need finer control, you can adjust the bounding box dimensions
individually by changing the macro \PreviewBbAdjust
with the
help of \renewcommand
. Its default value is
\newcommand \PreviewBbAdjust {-\PreviewBorder -\PreviewBorder \PreviewBorder \PreviewBorder}
This adjusts the left, lower, right and upper borders by the given
amount. The macro must contain 4 TeX dimensions after another,
and you may not omit the units if you specify them explicitly
instead of by register. PostScript points have the unit bp
.
lyx
This option is for the sake of LyX developers. It will output a few diagnostics relevant for the sake of LyX’ preview functionality (at the time of writing, mostly implemented for math insets, in versions of LyX starting with 1.3.0).
counters
This writes out diagnostics at the start and the
end of previews. Only the counters changed since the last output
get written, and if no counters changed, nothing gets written at
all. The list consists of counter name and value, both enclosed
in {}
braces, followed by a space. The last such pair is
followed by a colon (:
) if it is at the start of the preview
snippet, and by a period (.) if it is at the end. The order of
different diagnostics like this being issued depends on the order
of the specification of the options when calling the package.
Systems like preview-latex use this for keeping counters accurate when single previews are regenerated.
footnotes
This makes footnotes render as previews, and only as their footnote symbol. A convenient editing feature inside of Emacs.
The following options are just for debugging purposes of the package and similar to the corresponding TeX commands they allude to:
tracingall
causes lots of diagnostic output to appear in
the log file during the preview collecting phases of TeX’s
operation. In contrast to the similarly named TeX command, it
will not switch to \errorstopmode
, nor will it change the
setting of \tracingonline
.
showbox
This option will show the contents of the boxes
shipped out to the DVI files. It also sets \showboxbreadth
and
\showboxdepth
to their maximum values at the end of loading this
package, but you may reset them if you don’t like that.
Previous: Package options, Up: The LaTeX style file [Contents][Index]
\begin{preview}…\end{preview}
The preview
environment causes its contents
to be set as a single preview image. Insertions like figures and
footnotes (except those included in minipages) will typically lead
to error messages or be lost. In case the preview
package has not
been activated, the contents of this environment will be typeset
normally.
\begin{nopreview}…\end{nopreview}
The nopreview
environment will cause its
contents not to undergo any special treatment by the preview
package. When preview
is active, the contents will be discarded
like all main text that does not trigger the preview
hooks. When
preview
is not active, the contents will be typeset just like the
main text.
Note that both of these environments typeset things as usual when
preview is not active. If you need something typeset conditionally,
use the \ifPreview
conditional for it.
\PreviewMacro
If you want to make a macro like
\includegraphics
(actually, this is what is done by the
graphics
option to preview
) produce a preview image, you put a
declaration like
\PreviewMacro[*[[!]{\includegraphics}
or, more readable,
\PreviewMacro[{*[][]{}}]{\includegraphics}
into your preamble. The optional argument to \PreviewMacro
specifies the arguments \includegraphics
accepts, since this
is necessary information for properly ending the preview box. Note
that if you are using the more readable form, you have to enclose
the argument in a [{
and }]
pair. The inner braces are
necessary to stop any included []
pairs from prematurely ending
the optional argument, and to make a single {}
denoting an optional argument not get stripped away by TeX’s
argument parsing.
The letters simply mean
*
indicates an optional *
modifier, as in
\includegraphics*
.
[
^^A] indicates an optional argument in brackets. This syntax is somewhat baroque, but brief.
[]
also indicates an optional argument in brackets. Be sure to have encluded the entire optional argument specification in an additional pair of braces as described above.
!
indicates a mandatory argument.
{}
indicates the same. Again, be sure to have that additional level of braces around the whole argument specification.
?
delimiter{true case}{false case}is a conditional. The next character is checked against being equal to delimiter. If it is, the specification true case is used for the further parsing, otherwise false case will be employed. In neither case is something consumed from the input, so {true case} will still have to deal with the upcoming delimiter.
@
{literal sequence}will insert the given sequence literally into the executed call of the command.
-
will just drop the next token. It will probably be most
often used in the true branch of a ?
specification.
#
{argument}{replacement}is a transformation
rule that calls a macro with the given argument and replacement
text on the rest of the argument list. The replacement is used in
the executed call of the command. This can be used for parsing
arbitrary constructs. For example, the []
option could manually
be implemented with the option string ?[{#{[#1]}{[{#1}]}}{}
.
PStricks users might enjoy this sort of flexibility.
:
{argument}{replacement}is again a
transformation rule. As opposed to #
, however, the result of
the transformation is parsed again. You’ll rarely need this.
There is a second optional argument in brackets that can be used to
declare any default action to be taken instead. This is mostly for
the sake of macros that influence numbering: you would want to keep
their effects in that respect. The default action should use #1
for referring to the original (not the patched) command with the
parsed options appended. Not specifying a second optional argument
here is equivalent to specifying [#1]
.
\PreviewMacro*
A similar invocation
\PreviewMacro*
simply throws the macro and all of its
arguments declared in the manner above away. This is mostly useful
for having things like \footnote
not do their magic on their
arguments. More often than not, you don’t want to declare any
arguments to scan to \PreviewMacro*
since you would want the
remaining arguments to be treated as usual text and typeset in that
manner instead of being thrown away. An exception might be, say,
sort keys for \cite
.
A second optional argument in brackets can be used to declare any
default action to be taken instead. This is for the sake of macros
that influence numbering: you would want to keep their effects in
that respect. The default action might use #1
for referring to
the original (not the patched) command with the parsed options
appended. Not specifying a second optional argument here is
equivalent to specifying []
since the command usually gets thrown
away.
As an example for using this argument, you might want to specify
\PreviewMacro*[{[]}][#1{}]{\footnote}
This will replace a footnote by an empty footnote, but taking any optional parameter into account, since an optional paramter changes the numbering scheme. That way the real argument for the footnote remains for processing by preview-latex.
\PreviewEnvironment
The macro
\PreviewEnvironment
works just as \PreviewMacro
does,
only for environments.
\PreviewEnvironment*
And the
same goes for \PreviewEnvironment*
as compared to
\PreviewMacro*
.
\PreviewSnarfEnvironment
This macro does not typeset the original environment inside of a preview box, but instead typesets just the contents of the original environment inside of the preview box, leaving nothing for the original environment. This has to be used for figures, for example, since they would
\PreviewOpen
\PreviewClose
Those Macros form a matched preview pair. This is for macros that
behave similar as \begin
and \end
of an environment. It
is essential for the operation of \PreviewOpen
that the macro
treated with it will open an additional group even when the preview
falls inside of another preview or inside of a nopreview
environment. Similarly, the macro treated with \PreviewClose
will close an environment even when inactive.
\ifPreview
In case you need to know whether
preview
is active, you can use the conditional \ifPreview
together with \else
and \fi
.
Next: The preview images, Previous: The LaTeX style file, Up: For advanced users [Contents][Index]
You can use M-x customize-group RET preview-latex RET in order to customize these variables, or use the menus for it. We explain the various available options together with explaining how they work together in making preview-latex work as intended.
preview-LaTeX-command
When you generate previews on a buffer or a region, the command in
preview-LaTeX-command
gets run (that variable should only be
changed with Customize since its structure is somewhat peculiar, though
expressive). As usual with AUCTeX, you can continue working while
this is going on. It is not a good idea to change the file until after
preview-latex has established where to place the previews which it can
only do after the LaTeX run completes. This run produces a host of
pseudo-error messages that get parsed by preview-latex at the end of
the LaTeX run and give it the necessary information about where in
the source file the LaTeX code for the various previews is located
exactly. The parsing takes a moment and will render Emacs busy.
preview-LaTeX-command-replacements
This variable specifies transformations to be used before calling the configured command. One possibility is to have ‘\pdfoutput=0 ’ appended to every command starting with ‘pdf’. This particular setting is available as the shortcut ‘preview-LaTeX-disable-pdfoutput’. Since preview-latex can work with PDF files by now, there is little incentive for using this option, anymore (for projects not requiring PDF output, the added speed of ‘dvipng’ might make this somewhat attractive).
preview-required-option-list
preview-LaTeX-command
uses preview-required-option-list
in
order to pass options such as auctex, active and
dvips to the preview package. This means that the user
need (and should) not supply these in the document itself in case he
wants to be able to still compile his document without it turning into
an incoherent mass of little pictures. These options even get passed
in when the user loads preview explicitly in his document.
The default includes an option counters
that is controlled by the
boolean variable
preview-preserve-counters
This option will cause the preview package to emit information that will assist in keeping things like equation counters and section numbers reasonably correct even when you are regenerating only single previews.
preview-default-option-list
preview-default-preamble
If the document does not call in the package preview
itself (via
\usepackage
) in the preamble, the preview package is loaded using
default options from preview-default-option-list
and additional
commands specified in preview-default-preamble
.
preview-fast-conversion
This is relevant only for DVI mode. It defaults to ‘On’ and results in the whole document being processed as one large PostScript file from which the single images are extracted with the help of parsing the PostScript for use of so-called DSC comments. The bounding boxes are extracted with the help of TeX instead of getting them from Dvips. If you are experiencing bounding box problems, try setting this option to ‘Off’.
preview-prefer-TeX-bb
If this option is ‘On’, it tells preview-latex never to try to extract
bounding boxes from the bounding box comments of EPS files,
but rather rely on the boxes it gets from TeX. If you activated
preview-fast-conversion
, this is done, anyhow, since there are no
EPS files from which to read this information. The option
defaults to ‘Off’, simply because about the only conceivable reason to
switch off preview-fast-conversion
would be that you have some
bounding box problem and want to get Dvips’ angle on that matter.
preview-scale-function
preview-reference-face
preview-document-pt-list
preview-default-document-pt
preview-scale-function
determines by what factor
images should be scaled when appearing on the screen. If you specify a
numerical value here, the physical size on the screen will be that of
the original paper output scaled by the specified factor, at least if
Emacs’ information about screen size and resolution are correct. The
default is to let preview-scale-from-face
determine the scale
function. This function determines the scale factor by making the
size of the default font in the document match that of the on-screen
fonts.
The size of the screen fonts is deduced from the font
preview-reference-face
(usually the default face used for
display), the size of the default font for the document is determined
by calling preview-document-pt
.
This function consults the members of preview-document-pt-list
in
turn until it gets the desired information. The default consults first
preview-parsed-font-size
,
then calls preview-auctex-font-size
which asks AUCTeX about any size specification like 12pt to
the documentclass that it might have detected when parsing the document, and
finally reverts to just assuming preview-default-document-pt
as
the size used in the document (defaulting to 10pt).
If you find that the size of previews and the other Emacs display
clashes, something goes wrong. preview-parsed-font-size
is
determined at \begin{document}
time; if the default font size
changes after that, it will not get reported. If you have an outdated
version of preview.sty in your path, the size might not be
reported at all. If in this case AUCTeX is unable to find a size
specification, and if you are using a document class with a different
default value (like KomaScript), the default fallback assumption will
probably be wrong and preview-latex will scale up things too large.
So better specify those size options even when you know that LaTeX
does not need them: preview-latex might benefit from them. Another
possibility for error is that you have not enabled AUCTeX’s document
parsing options. The fallback method of asking AUCTeX about the size
might be disabled in future versions of preview-latex since in
general it is more reliable to get this information from the LaTeX
run itself.
preview-fast-dvips-command
preview-dvips-command
The regular command for turning a DVI file into a single
PostScript file is preview-fast-dvips-command
, while
preview-dvips-command
is used for cranking out a DVI
file where every preview is in a separate EPS file. Which of
the two commands gets used depends on the setting of
preview-fast-conversion
. The printer specified here by default
is -Pwww by default, which will usually get you scalable fonts
where available. If you are experiencing problems, you might want to try
playing around with Dvips options (See (dvips)Command-line options).
The conversion of the previews into PostScript or EPS files gets started after the LaTeX run completes when Emacs recognizes the first image while parsing the error messages. When Emacs has finished parsing the error messages, it activates all detected previews. This entails throwing away any previous previews covering the same areas, and then replacing the text in its visual appearance by a placeholder looking like a roadworks sign.
preview-nonready-icon-specs
This is the roadworks sign displayed while previews are being prepared. You may want to customize the font sizes at which preview-latex switches over between different icon sizes, and the ascent ratio which determines how high above the base line the icon gets placed.
preview-error-icon-specs
preview-icon-specs
Those are icons placed before the source code of an opened preview and, respectively, the image specs to be used for PostScript errors, and a normal open preview in text representation.
preview-inner-environments
This is a list of environments that are regarded as inner levels of an
outer environment when doing preview-environment
. One example
when this is needed is in
\begin{equation}\begin{split}…\end{split}\end{equation}
, and
accordingly split
is one entry in
preview-inner-environments
.
Next: Misplaced previews, Previous: The Emacs interface, Up: For advanced users [Contents][Index]
preview-image-type
preview-image-creators
preview-gs-image-type-alist
What happens when LaTeX is finished depends on the configuration of
preview-image-type
. What to do for each of the various settings
is specified in the variable preview-image-creators
. The options
to pass into Ghostscript and what Emacs image type to use is specified
in preview-gs-image-type-alist
.
preview-image-type
defaults to png
. For this to work,
your version of Ghostscript needs to support the png16m device.
If you are experiencing problems here, you might want to reconfigure
gs-image-type-alist
or preview-image-type
. Reconfiguring
preview-image-creators
is only necessary for adding additional
image types.
Most devices make preview-latex start up a single Ghostscript process
for the entire preview run (as opposed to one per image) and feed it
either sections of a PDF file (if PDFLaTeX was used), or
(after running Dvips) sections of a single PostScript file or separate
EPS files in sequence for conversion into PNG format
which can be displayed much faster by Emacs. Actually, not in sequence
but backwards since you are most likely editing at the end of the
document. And as an added convenience, any preview that happens to be
on-screen is given higher priority so that preview-latex will first
cater for the images that are displayed. There are various options
customizable concerning aspects of that operation, see the customization
group Preview Gs
for this.
Another noteworthy setting of preview-image-type
is
‘dvipng’: in this case, the ‘dvipng’
program will get run on DVI output (see below for PDF).
This is in general much faster than Dvips and Ghostscript. In that
case, the option
preview-dvipng-command
will get run for doing the conversion, and it is expected that
preview-dvipng-image-type
images get produced (‘dvipng’ might be configured for other image
types as well). You will notice that preview-gs-image-type-alist
contains an entry for dvipng
: this actually has nothing to with
‘dvipng’ itself but specifies the image type and Ghostscript device
option to use when ‘dvipng’ can’t be used. This will obviously be
the case for PDF output by PDFLaTeX, but it will also happen
if the DVI file contains PostScript specials in which case the
affected images will get run through Dvips and Ghostscript once
‘dvipng’ finishes.
Note for pLaTeX and upLaTeX users: It is known that dvipng
is not compatible with pLaTeX and upLaTeX. If
preview-image-type
is set to ‘dvipng’ and (u)pLaTeX is
used, ‘dvipng’ just fails and preview-latex falls back on Dvips
and Ghostscript.
preview-gs-options
Most interesting to the user perhaps is the setting of this variable. It contains the default antialiasing settings -dTextAlphaBits=4 and -dGraphicsAlphaBits=4. Decreasing those values to 2 or 1 might increase Ghostscript’s performance if you find it lacking.
Running and feeding Ghostscript from preview-latex happens asynchronously again: you can resume editing while the images arrive. While those pretty pictures filling in the blanks on screen tend to make one marvel instead of work, rendering the non-displayed images afterwards will not take away your attention and will eventually guarantee that jumping around in the document will encounter only prerendered images.
Previous: The preview images, Up: For advanced users [Contents][Index]
If you are reading this section, the first thing is to check that your problem is not caused by x-symbol in connection with an installation not supporting 8-bit characters (see x-symbol interoperation). If not, here’s the beef:
As explained previously, Emacs uses pseudo-error messages generated by
the ‘preview’ package in order to pinpoint the exact source
location where a preview originated. This works in running text, but
fails when preview material happens to lie in macro arguments, like the
contents of \emph
. Those macros first read in their entire
argument, munge it through, perhaps transform it somehow, process it and
perhaps then typeset something. When they finally typeset something,
where is the location where the stuff originated? TeX, having read in
the entire argument before, does not know and actually there would be no
sane way of defining it.
For previews contained inside such a macro argument, the default behaviour of preview-latex is to use a position immediately after the closing brace of the argument. All the previews get placed there, all at a zero-width position, which means that Emacs displays it in an order that preview-latex cannot influence (currently in Emacs it is even possible that the order changes between runs). And since the placement of those previews is goofed up, you will not be able to regenerate them by clicking on them. The default behaviour is thus somewhat undesirable.
The solution (like with other preview problems) is to tell the LaTeX
‘preview’ package how to tackle this problem (see The LaTeX style file). Simply, you don’t need \emph
do anything at all
during previews! You only want the text math previewed, so the solution
is to use \PreviewMacro*\emph
in the preamble of your document
which will make LaTeX ignore \emph
completely as long as it is
not part of a larger preview (in which case it gets typeset as
usual). Its argument thus becomes ordinary text and gets treated like
ordinary text.
Note that it would be a bad idea to declare
\PreviewMacro*[{{}}]\emph
since then both \emph
as
well as its argument would be ignored instead of previewed. For
user-level macros, this is almost never wanted, but there may be
internal macros where you might want to ignore internal arguments.
The same mechanism can be used for a number of other text-formatting
commands like \textrm
, \textit
and the like. While they
all use the same internal macro \text@command
, it will not do to
redefine just that, since they call it only after having read their
argument in, and then it already is too late. So you need to disable
every of those commands by hand in your document preamble.
Actually, we wrote all of the above just to scare you. At least all of
the above mentioned macros and a few more are already catered for by a
configuration file prauctex.cfg that gets loaded by default
unless the ‘preview’ package gets loaded with the noconfig
option. You can make your own copy of this file in a local directory
and edit it in case of need. You can also add loading of a file of your
liking to preview-default-preamble
,
or alternatively do the
manual disabling of your favorite macro in
preview-default-preamble
,
which is customizable in the Preview Latex group.
Previous: The preview images, Up: For advanced users [Contents][Index]