Scenario: I have a main Latex file (main.tex) in which I include a subfile (appendix.tex) using the subfiles package.
Role of appendix.tex: It further includes all the appendices as subfiles kept in an appendix subfolder, so that I just need to include the appendix.tex in the main.tex file.
Current Situation: I have to manually list the appendices in appendix.tex which can be cumbersome to manage.
Target: I want to create a foreach loop kind of thing in the appendix.tex file such that it looks in the appendix subfolder and includes each of the .tex files present in it.
Question: How can this be done?
This can be relatively easy implemented with python.sty from here. This would require you to make sure that the style file and python is available on all machines were you plan to compile this document, but should be more portable than using shell scripts or preprocessors like cpp.
Probably easiest done externally via a shell script. Provide some more info on your OS (Win/Apple/Linux) and someone will no doubt provide the necessary script.
I did it the other way, with a python pre-processor for LaTeX. My preprocessor generates tables and allows raw python to be put into the LaTeX file. Since python.sty requires that LaTeX be compiled with shell escapes, this may be a better way.
I can post the preprocessor if there is interest.
Related
I want to use isabelle build -D xxx to produce a LaTeX .tex file out of an Isabelle .thy file.
But Isabelle checks all the theory dependencies, and all the related .thy files must be involved.
Is it possible that I casually use a .thy file that has syntax errors to produce a .tex file? In fact I only need a part of it to write a paper.
Does that mean you want to write a paper based on a faulty or incomplete formal theory?
The Isabelle document preparation system was intended to publish formal theories that actually work out, with nice typography so that this does not look like "code". So all the defaults are for producing LaTeX from well-formed and checked theories.
Nonetheless, there are numerous ways to get unofficial LaTeX output from the system. A very basic mechanism is the latex print mode. Various diagnostic commands of Isabelle allow such print mode specifications in round parentheses, e.g. like this:
thm (latex) exI exE
or
print_statement (latex) exI exE
You can do this interactively and copy-paste the output into your raw tex file. You need to ensure that it gets proper surroundings with environments from the isabelle.sty file.
To the best of my knowledge, no. The LaTeX generation requires the file to be processed successfully, e.g. due to notation (latex) commands, and due to antiquotations.
If you only need parts of your file, simply copy’n’paste it from the generated .tex file or, if you want something more automated, have a look at the Generate TeX Snippets wiki page.
I got code::blocks as my C/C++ compiler along with C++ for dummies, but my only problem is with a obscure scripting language that I have never heard of before; "Squirrel". Is it possible to change the scripting language of code::blocks to something more familiar to me, like lua?
It seems doable in theory. Whether it is doable in practice, hard to say. Here is what you would need to do:
create a folder src/sdk/scripting/lua in which you put the Lua interpreter (+ Lua libraries like io, math etc) source code and create project file for it
create a folder in src/sdk/scripting/lua_bindings where you put your Lua bindings: the C++ files that allow Lua scripts access to the host application. I recommend you use a tool like SWIG to generate them (codeblocks uses SqPlus). This involves determining what code-blocks functions/classes you want to export, creating one or more .i files, running SWIG on them, put the generated files going into "lua_bindings"; create a DLL project for the bindings
Create a src/lua_scripts in which you put the Lua equivalent of scripts found in src/scripts; or rather, a subset of those scripts, because it is unlikely you will want to export to Lua everything that is available via Squirrel if you're just following examples from a book
Find where Squirrel interpreter is instantiated in codeblocks and where RegisterBindings is called; replace it with instantiation of a Lua interpreter and call your luaopen_codeblocks which you will have created via SWIG (no need for a RegisterLuaBindings if you use SWIG, it does that for you)
Find where the various scripts are called by codeblocks (see http://wiki.codeblocks.org/index.php?title=Scripting_Code::Blocks). Call the equivalent Lua scripts (which are in lua_scripts -- you'll surely have to copy this to the installation folder for code-blocks). For example the startup.script, which is the Squirrel script that codeblocks automatically looks for at startup, is run by the following code in src/src/app.cpp:
// run startup script
try
{
wxString startup = ConfigManager::LocateDataFile(_T("startup.script"), sdScriptsUser | sdScriptsGlobal);
if (!startup.IsEmpty())
Manager::Get()->GetScriptingManager()->LoadScript(startup);
}
catch (SquirrelError& exception)
{
Manager::Get()->GetScriptingManager()->DisplayErrors(&exception);
}
I think that's about it.
Naturally based on how extensive your scripting is, you may cut some corners, but as you can see, this is not for the faint of heart!
I use F# as a scripting language with FSI. Is there a way to include another fsx file in my script? I want to be able to break my scripts into multiple files for larger tasks.
Thanks.
If I understand the question correctly, you should be able to use the #load directive to do what you want. See http://msdn.microsoft.com/en-us/library/dd233175.aspx.
I'd like to create multiple documents (output as PDFs after running pdflatex) whose source is from one file.
Example:
\documentclass{article}
\begin{document}
This text will appear in the first PDF.
\end{document}
\begin{document}
This text will appear in the second PDF.
\end{document}
This would be particularly useful because:
I could keep everything in 1 file, with a single, consistent preamble.
I could use ifthen or other loops to automatically generate various alternative forms of a document.
AFAIK this is not possible without some preprocessing of your file, i.e. using a scripting language to produce two separate documents then compiling them separately. Even then I don't think it's a good idea.
The first reason you think this would be useful is handled by putting your preamble in a separate document that is included in as many documents as you want using \include. The second aspect can be handled by using Makefiles and putting the conditional branching to build particular versions of a document in there.
I wrote a really simple preprocessor for LaTeX that embeds Ruby code directly into .tex files for this purpose and use the ERB template engine. Here's the source code on Google Code, if you want to take a look. There's not much to it, though I regularly use it from a Ant/latexmk-based build script and it has proved very useful for generating multiple version of my résumé. It works equally well on Linux/Mac OS X/Windows, assuming you have a working LaTex and Ruby installation.
So after writing a large .tex file and using many packages I want to archive everything, not just the .tex .jpg files, but also the .sty files.
This is because sometimes some options in the sty files are changed, and then I can't compile the file.
The "problem" is that in using Ubuntu, I already installed all the packages in my system.
I don't want to have to copy them manually.
Is there a program that can do this automatically?
Thanks.
See https://texfaq.org/FAQ-filesused, quote:
All the files used by this document When you’re sharing a document
with someone else (perhaps as part of a co-development cycle) it’s as
well to arrange that both correspondents have the same set of
auxiliary files, as well as the document in question. Your
correspondent obviously needs the same set of files (if you use the
url package, she has to have url too, for example). But
suppose you have a bug-free version of the shinynew package but her
copy is still the unstable original; until you both realise what is
happening, such a situation can be very confusing.
The simplest solution is the LaTeX \listfiles command. This places a
list of the files used and their version numbers in the log file. If
you extract that list and transmit it with your file, it can be used
as a check-list in case that problems arise.
Note that \listfiles only registers things that are input by the
“standard” LaTeX mechanisms (\documentclass, \usepackage,
\include, \includegraphics and so on). The \input command, as
modified by LaTeX and used, with LaTeX syntax, as:
\input{mymacros}
records file details for mymacros.tex, but if you use TeX primitive
syntax for \input, as:
\input mymacros
mymacros.tex won’t be recorded, and so won’t listed by \listfiles
— you’ve bypassed the mechanism that records its use.
The snapshot package helps the owner of a LaTeX document obtain
a list of the external dependencies of the document, in a form that
can be embedded at the top of the document. The intended use of the
package is the creation of archival copies of documents, but it has
application in document exchange situations too.
The bundledoc system uses the snapshot to produce an archive
(e.g., tar.gz or zip) of the files needed by your document; it
comes with configuration files for use with TeX Live-Unix and MiKTeX.
It’s plainly useful when you’re sending the first copy of a document.
The mkjobtexmf finds which files are used in a “job”, either via the
-recorder option of TeX, or by using the (Unix) command strace to
keep an eye on what TeX is doing. The files thus found are copied (or
linked) to a directory which may then be saved for transmission or
archiving.
Latex logfiles indicate all files loaded as follows:
Files specified using absolute paths are shown (\$PATH followed by whitespace (a space or a newline; I think Tex forbids whitespace in paths, certainly paths with whitespace are a pairn to pass to \input);
Local paths are the same except they have a dot: (.\$PATH followed by whitespace
Fonts are shown within <...>.
You can easily scrape these filenames out of the .log file.