Please don't refer me to 'newclude' package because it doesn't work.
\documentclass[10pt,a4paper]{article}
\usepackage[american]{babel}
\begin{document}
Contents/body
\end{document}
how so? i've never used it in anger, but it seemed to work in the one
small test i did.
anyway, its predecessor, includex _does_ work (or did, 10 years ago
when i did a big project using it. (though i find i have a file
called "breaks_includex" so it obviously wasn't 100% solid...)
note that its command \includedoc is properly named -- it's an
"include-like" thing.
>\documentclass[10pt,a4paper]{article}
>\usepackage[american]{babel}
>\begin{document}
> Contents/body
>\end{document}
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=multidoc
is a collection of alternatives.
--
Robin Fairbairns, Cambridge
There was no anger at all, but I spent some time on newclude and it
didn't work for me. Perhaps the fault was mine. I will have a go at
\includedoc; previously I tried \includeenv.
I read in the Latex Companion by Mittelbach et al. that the book used
the the verbatim environment of the fancyvrb package to achieve a
similar objective. Does anyone know the tricks the played?
Thanks.
fancyvrb have a feacture where one can specify two strings and it will
then input (verbatimly) the content between those two lines. Listings
can do something similar.
Not sure if it is usable for regular document processing though.
--
/daleif (remove RTFSIGNATURE from email address)
LaTeX FAQ: http://www.tex.ac.uk/faq
LaTeX book: http://www.imf.au.dk/system/latex/bog/ (in Danish)
Remember to post minimal examples, see URL below
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=minxampl
http://www.minimalbeispiel.de/mini-en.html
> Not sure if verbatim is usable for regular document processing though.
No, I have tried it.
> I will have a go at \includedoc; previously I tried \includeenv.
The \includedoc macro is defined in newclude.sty as
\newcommand\includedoc{\md@check@star\Expand\sc@star@nothing\In{%
\IncludeEnv##1{document}{}}%
}
Unfortunately \Expand is not defined in newclude.sty or moredef.sty.
Unpon compliation I get "Undefined sontrol sequence \Expand"
(i'm never quite sure what those things mean)
>> I will have a go at \includedoc; previously I tried \includeenv.
>
>The \includedoc macro is defined in newclude.sty as
>
>\newcommand\includedoc{\md@check@star\Expand\sc@star@nothing\In{%
> \IncludeEnv##1{document}{}}%
>}
>
>Unfortunately \Expand is not defined in newclude.sty or moredef.sty.
>Unpon compliation I get "Undefined sontrol sequence \Expand"
as i said, i've not used newclude.sty, only includex.sty (from the
"unsupported" directory). when i was doing the project i mentioned,
includex's \includedoc served me well.
--
Robin Fairbairns, Cambridge
I often want to do the same for tikz pictures and the like. Compile
them as standalone documents or input in the main document. I usually
did that with various kludges, but today I took some time and wrote a
proper package. It lacks the features of preamble processing (that I
don't need) available in newclude but it does verbatim-like line-by-
line gobbling. Any suggestions for improvements or a better name
(currently: docmute) are welcome.
Usage:
In the main document put the usual:
\usepackage{docmute}
and at the top of each document that you want to input/include put:
\csname docmute\endscname
This will activate the preamble gobbling if you input the file in the
main document, but otherwise it won't interfere with standalone
compilation. Alternatively, instead of modifying all the subsidiary
documents, you can put in the main document:
\begin{document}
\let\documentclass=\docmute
and then use \input / \include with unmodified documents.
How it works:
The \docmute command starts gobbling everything line-by-line until a
line with \begin{document} is found. At that point \enddocument is
redefined to stop the input and the input is started.
Limitations:
The \docmute command has to be issued in the same file as \begin
{document}. I couldn't figure out a way to make gobbling work across
files, I'm not even sure if it is possible. And there might be some
other limitations that I'm not aware of.
If this is useful for other people, I can try to write some proper
documentation and put everything on CTAN.
Cheers,
Tomek
% Begin file: docmute.sty
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{docmute}%
[2009/09/30 v1.0 LaTeX2e package to allow inputting standalone
documents]
\@ifundefined{docmute}{}{\endinput}
\def\docmute{\begingroup\catcode`\^^M=12 \docmute@gobblepreamble}
{\catcode`\^^M=12 %
\gdef\docmute@gobblepreamble#1^^M{\docmute@doctest#1\begin\@nil
\docmute@continue}%
}
\def\docmute@docenv{document}
\def\docmute@doctest#1\begin#2{
\def\docmute@thisenv{#2}%
\ifx\docmute@thisenv\docmute@docenv
\endgroup % restore catcodes
\let\docmute@continue=\docmute@afterpreamble
\docmute@afterdoc
\else
\let\docmute@continue=\docmute@gobblepreamble
\fi
}
\def\docmute@afterpreamble{
\let\docmute@enddocument=\enddocument
\def\enddocument{
\let\enddocument=\docmute@enddocument
\endinput
\begingroup
}
}
\def\docmute@afterdoc#1\begin\@nil{#1}
\endinput
% EOF
> ... to stop the input and the input is started.
This statement is not clear.
The unsupported includex.sty works fine, but I will also try docmute
in a moment. Thanks!
Robin, why not bring includex back to life?
i thought docmute (which i've not analysed properly) seemed an
unsatisfactory solution to your problem, since it involves patching
every file you need to include
>The unsupported includex.sty works fine, but I will also try docmute
>in a moment. Thanks!
>
>Robin, why not bring includex back to life?
actually, i have corresponded with matt swift about the possibility of
taking over his stuff; in principle i've his permission.
in practice, i've so little energy at the moment, i'm not really
managing much creative. some day, perhaps.
--
Robin Fairbairns, Cambridge
Assuming that in each subsidiary file, the desired contents lie
between \begin{document} ....... \end{document}, I agree that the
cleanest approach is a latex package, if available. If not, the
alternative approach of coding your own "pre-compile" (e.g. in java,
c, or your programming editor's macro language) should be very easy.
Simply create Subsidiary_files_to_include.txt, which looks like
<path>/file1.tex
<path>/file2.tex
...
Then have pre_compile.java (et al) open Subsidiary_generated_file.tex,
delete all of its lines (if any), loop through the pathname-filenames
to include, open each one, find the first occurrences of \begin
{document} and \end{document}, and append the desired lines to
Subsidiary_generated_file.tex, perhaps wrapping the inserts around
something like
%% Start of insert from <path>/file1.txt
...
%% End of insert from <path>/file1.txt
<blank line>
With this approach, Subsidiary_generated_file.tex is a throwaway file,
that never needs to be backed up or edited directly, and main_file.tex
(et al) simply needs the appropriately placed \input{Subsidiary...tex}
command.
Possibly inappropriate shortcut is to store subsidiary files all in
same directory, eliminate the Subsidiary_files_to_include.txt file,
and have pre_compile.java loop through this directory. However, this
shortcut may require renaming tex files to F01_file1.tex,
F02_file2.tex, ... to control the order that the files are inserted.
Of what use is a command like the following in the includex package:
\let\MDSavedauthor\author
\renewcommand\author[1]{%
\MDSavedauthor{#1\\and Robin Fairbairns}%
}
It means that
1. After the package is loaded, every call to \author will print names
including 'Robin Fairbairns', except \author is redefined thereafter;
at least that has been my experience.
2. A call as \author{} will prompt an error: 'There is no line here to
end.'
Thanks
That's not in the CTAN version (which seems to be the most current I
can find)
--
Joseph Wright
You don't have to patch every file. All you need is:
\let\documentclass=\docmute
in the main document and you can input/include whole documents as any
other file.
However, I discovered some other problems:
- subsidiary documents cannot input other subsidiary documents
- there are some unwanted spaces included
I'm rewriting this package atm. One thing I'm struggling with is how
to redefine the \enddocument command such that everything after \end
{document} is thrown away. \endinput is not sufficient, because with:
\end{document} foo
`foo' still goes through. Currently I have:
\def\enddocument{%
\endinput
\aftergroup\ignorespaces
}%
which at least removes the unwanted spaces but I don't know how to
remove everything else on that line.
Cheers,
Tomek
i can't remember why i put the code in there in the first place
(possibly to point out to someone that something _else_ was
ridiculous).
further, i can't remember how that version got out into the world.
i _do_ (vaguely) remember being embarrassed some time back that
someone had a copy of it, and taking appropriate action.
--
Robin Fairbairns, Cambridge
The 'docmute' package doesn't work for me; perhaps I have used it
wrongly. Please see samples below. Grateful for any help.
%% main file:
\documentclass{article}
\usepackage{docmute}
\usepackage{xcolor}
\usepackage{lipsum}
\xglobal\definecolor{xred}{rgb}{1.00,0.00,0.00}
\xglobal\definecolor{xgreen}{rgb}{0.00,0.50,0.00}
\begin{document}
\let\documentclass\docmute
\title{Test of \texttt{docmute} Package}
\author{P}
\maketitle
\lipsum[1-4]
\include{includedfile}
\color{xgreen}
\lipsum[1-4]
\end{document}
%% includedfile:
\documentclass{article}
\usepackage{xcolor}
\usepackage{lipsum}
\xglobal\definecolor{xred}{rgb}{1.00,0.00,0.00}
\xglobal\definecolor{xgreen}{rgb}{0.00,0.50,0.00}
\begin{document}
\color{xred}
\lipsum[1-4]
\normalcolor
\end{document}
%% docmute package:
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{docmute}[2009/09/30 v1.0 Input standalone documents]
\@ifundefined{docmute}{}{\endinput}
\def\docmute{\begingroup\catcode`\^^M=12\docmute@gobblepreamble}
{\catcode`\^^M=12%
\gdef\docmute@gobblepreamble#1^^M{\docmute@doctest#1\begin\@nil
\docmute@continue}%
}%
\def\docmute@docenv{document}
\def\docmute@doctest#1\begin#2{%
\def\docmute@thisenv{#2}%
\ifx\docmute@thisenv\docmute@docenv
\endgroup % restore catcodes
\let\docmute@continue\docmute@afterpreamble
\docmute@afterdoc%
\else
\let\docmute@continue\docmute@gobblepreamble
\fi
}
\def\docmute@afterpreamble{
\let\docmute@enddocument\enddocument
\def\enddocument{
\let\enddocument\docmute@enddocument
No worries, help is on the way ;-)
Indeed, something is not right with my line-by-line gobbling
implementation, but I don't know what yet. I dropped it for the time
being in favour of a simpler approach with a delimited macro. Below is
the next iteration of the docmute package that should work with your
example. There are two options available now:
1) persistent - with this option \let\documentclass=\docmute is not
necessary any more
2) nested - allows to input/include documents that already input/
include other documents (there is \begingroup ... \endgroup around
them).
Cheers,
Tomek
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{docmute}%
[2009/10/02 v1.1alpha Input standalone documents]
\@ifundefined{docmute}{}{\endinput}
\def\docmute@docenv{document}
\long\def\docmute@gobblepreamble#1\begin#2{%
\def\docmute@thisenv{#2}%
\ifx\docmute@thisenv\docmute@docenv
\let\docmute@continue=\docmute@afterpreamble
\else
\let\docmute@continue=\docmute@gobblepreamble
\fi
\docmute@continue
}
\let\docmute@document=\document
\let\docmute@enddocument=\enddocument
\let\docmute@afterbegindoc=\relax
\def\docmute@beforeenddoc{%
\let\enddocument=\docmute@enddocument
\begingroup
}
\def\docmute@afterpreamble{%
\docmute@afterbegindoc
\def\enddocument{%
\docmute@beforeenddoc
\endinput
\aftergroup\ignorespaces
}%
\ignorespaces
}
\let\docmute=\docmute@gobblepreamble
%
\DeclareOption{persistent}{%
\def\document{%
\docmute@document
\let\documentclass=\docmute
}
}
\DeclareOption{nested}{%
\let\docmute@afterbegindoc=\begingroup
\let\docmute@beforeenddoc=\relax
}
\ProcessOptions
%
\endinput
Well done! It worked, but only with the 'persistent' option enabled. I
therefore zapped the superfluous 'persistent' option from the package,
since without it the package won't work.
Also, it would be nice to provide an option for using/choosing or not
using the \clearpage command inherited from the kernel's \include (or
\@include). The 'includex' package provides for this.
Cheers
It will work if you put '\csname docmute\endcsname' at the top of the
subsidiary document(s). That was my idea at least, but now that you
mentioned it, maybe it's better to hardwire this option and always
load like this. WDYT?
> Also, it would be nice to provide an option for using/choosing or not
> using the \clearpage command inherited from the kernel's \include (or
> \@include). The 'includex' package provides for this.
You can always use \input instead of \include. Or do you really mean
\include without the \clearpage?
Cheers,
Tomek
> .. maybe it's better to hardwire this option and always load like this. WDYT?
Yes, I think that will be better since then the user doesn't have to
bother about putting '\csname docmute\endcsname' at the top of the
subsidiary document(s).
> Or do you really mean \include without the \clearpage?
Yes, something like providing a macro \include* which doesn't use
\clearpage. In this way the user can decide whether or not he needs or
wants to use the legacy \include or the new \include*.
Once again, well done and thanks!
Not having \clearpage breaks the use of \includeonly for producing
parts of a single document. If you want to produce different
documents
from the same input files, use a different mechanism.
Donald Arseneau
aiui (on the one occasion i actually _talked_ to matt about it, in
1995), his ambition was that newclude _wouldn't_ need the \clearpage.
i can (sort of vaguely) see how that might be done; i've never done
more than mental sketches of actually coding it, and i suspect i
couldn't get it right.
but then, the op said that newclude "didn't work for him", iirc.
--
Robin Fairbairns, Cambridge
OK, I will make the option 'permanent' permanent ;)
> > Or do you really mean \include without the \clearpage?
>
> Yes, something like providing a macro \include* which doesn't use
> \clearpage. In this way the user can decide whether or not he needs or
> wants to use the legacy \include or the new \include*.
I'm not sure if this package is the right place to implement such a
command. All I wanted to provide is a simple way to suppress the
preamble part of the inputted document(s). I think that extensions to
the standard inclusion mechanism are better done in a separate
package.
Cheers,
Tomek