Journal home page
General information Submit an item Download style files Copyright Contact us |
Ask Nelly is a question and answer column. Nelly is the quiet person who sits at the back corner desk, who knows a lot, and when asked any question is always ready with a patient answer. If Nelly doesn't know the answer, Nelly will know an expert who has the answer. Feel free to Ask Nelly about any aspect of LaTeX, TeX, Context, etc.
|
|
Q: I have heard that pdfTeX has capabilities beyond those available with TeX alone. What is different when I click on the pdfLaTeX rather than the LaTeX icon in WinEdt? A: First, it is somewhat misleading to speak of "pdflatex" in this context. Here is a recap of the basic TeX "engines" (actual binaries):
Second, and to get to your real question, you heard right that pdfTeX has capabilities beyond the original TeX. Two main new features in pdftex that come immediately to mind are:
Also, etex has additional debugging information available from \tracingall. This has proven helpful for tracing obscure problems. It has a number of other additional programming features, but no significant output-related features. Most other features often associated with PDFs (hyperlinks, colors, etc.) can be achieved with the original TeX. There are related advanced features that are part of the PDF document format, which of course pdftex gives access to, but this is beyond the scope of your question and this answer. See the pdftex manual.
A (follow-up): That's exactly right. The distinction is created when the .fmt files mentioned above are made. Invoking a binary named "pdflatex" reads the so-called "format file" pdflatex.fmt, which was created (in teTeX and TeX Live) by reading the file pdflatex.ini. Similarly, invoking a binary named "latex" reads the format file latex.fmt, which was created by reading the file latex.ini. In both cases, the exact same LaTeX macro files are read. The difference is that latex.ini sets \pdfoutput=0 (\pdfoutput is a new primitive parameter in pdfTeX-based engines). This, finally, is what makes pdf(e)tex's output be DVI instead of PDF. (pdflatex.ini leaves \pdfoutput=1, meaning to output PDF.) The image-reading code and such are all implemented internally to depend on \pdfoutput. I should say that the files might not be named "whatever.ini" in other distributions, and the exact names of the .fmt files aren't necessarily identical, but that is all an implementation-dependent issue. The underlying setting of \pdfoutput must be the same; that is the primitive parameter which controls the behavior. (This is true in the freely available TeX systems that I'm aware of. Of course I do not know how the proprietary implementations are implemented!) Final dangerous bend: there are actually even more steps done behind the scenes, so that the .fmt files can get created on the fly instead of users having to create them explicitly, but that's not germane to your pdf question.
A: This is, unfortunately, a common problem in several fields of science. On the bright side, this means that several other people came across these problems and solved them. We can just use their expertise. Let's take it in three steps.
A: This is a common problem. Not only does it occur whenever one wants to explain something in more detail in between "enumerate" entries, but also when creating a presentation using, for example, the Beamer package, and one enumerated list spans more than one slide. The way to do this is to creat an auxiliary counter in the preamble of your document like this: \newcounter{saveenumi} Then, whenever you want to end a numbered list, save the current value of its counter in your newly defined counter like this: \begin{enumerate} \item ... \item ... \item ... \setcounter{saveenumi}{\theenumi} \end{enumerate} Now you can type additional text, or end your slide and begin a new one, and then, n your next enumerate environment, just restore the saved counter, and continue where you left off: \begin{enumerate} \setcounter{enumi}{\thesaveenumi} \item ... \item ... \item ... \end{enumerate} Please note the difference between enumi and theenumi, as well as between saveenumi and thesaveenumi. In order to read the value of a counter, use its name prefixed with "the", and in order to store something in a counter, use its name without any prefix. There is no need to define the version with "the": LaTeX takes care of that automatically. In case you have an enumerate environment within an enumerate environment (within an enumerate environment, etc.) then just create an additional new counters (or two or three...), like this: \newcounter{saveenumi} \newcounter{saveenumii} \newcounter{saveenumiii} And at the end of your list, store all relevant counters: \setcounter{saveenumi}{\theenumi} \setcounter{saveenumii}{\theenumii} \setcounter{saveenumiii}{\theenumiii} and restore them again when you begin the new list: \setcounter{enumi}{\thesaveenumi} \setcounter{enumii}{\thesaveenumii} \setcounter{enumiii}{\thesaveenumiii} That should do the trick. For further customisations to enumerate, itemize and description lists, including functionality shown here, see the enumitem package, by Javier Bezos.
|
Page generated June 9, 2010 ; TUG home page; join TUG/renew membership; webmaster; facebook; x; mastodon.