![](https://secure.gravatar.com/avatar/8b3c344f0adba6016612e05447039f44.jpg?s=120&d=mm&r=g)
My latest project is almost finished. I have a few comments and questions. The book consists of one part with five unnumbered chapters followed by a second part of 101 numbered chapters, and some endmatter. I was unable to make the Context version of the TOC to single space these 110 or so chapter entries which made the whole TOC longer (more pages) than desired. So I threw Eplain into the mix and typeset the TOC only using the Eplain macros. If there is a way to single space the TOC using the regular Context macros I will be happy to eliminate the Eplain, which may solve some of the other problems. The last six pages consist of an order form, a page of text, and another order form, all backed up by blank pages for six pages total. The order form is created with some \framedtext and \starttable trickery. It compiles fine by itself but gives errors in the \starttable etc. when combined with the main body of the book. It will also coexist with the front matter, so eplain is probably not the culprit. In any case at the moment I have two correct pdfs which I will try to knit together with psmerge or something similar. I used a conventional construction of the job, with a main file which calls subordinate files. In this mode I ended up with two unwanted blank pages after the index. If however I put the \stoptext statement at the end of the main subordinate file the unwanted blank pages disappear. Here is the construction of the main file: ------------------------------ \input fonts.tex \input macros.tex \input part.tex \starttext \startfrontmatter \input half.tex \input title.tex {\tfx \input copy.tex } \noheaderandfooterlines \leftline{\tfb\bf\ss Table of Contents} \blank[big] \readtocfile\rm \page[yes] \noheaderandfooterlines \stopfrontmatter \startbodymatter \setupwhitespace[medium] \noheaderandfooterlines \input body.tex %\input order.tex %the last six pages start here %\input flyer.tex %\input order.tex \stopbodymatter \stoptext ----------------------------- If I insert a \stoptext statement at the end of the body.tex file then I lose the unwanted blank pages. Are they a byproduct of the \stopbodymatter statement? -- John Culleton Able Typesetters and Indexers http://wexfordpress.com
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
At 18:40 05/05/2004, you wrote:
using the Eplain macros. If there is a way to single space the TOC using the regular Context macros I will be happy to eliminate the Eplain, which may solve some of the other problems.
what is single spacing a toc? with regards to including eplain text, why not typesetting it as a separate document, and then do something \externalfigure[eplaintoc.pdf][width=\textwidth,height=\textheight] Hans
![](https://secure.gravatar.com/avatar/8b3c344f0adba6016612e05447039f44.jpg?s=120&d=mm&r=g)
On Wednesday 05 May 2004 02:07 am, Hans Hagen wrote:
At 18:40 05/05/2004, you wrote:
using the Eplain macros. If there is a way to single space the TOC using the regular Context macros I will be happy to eliminate the Eplain, which may solve some of the other problems.
what is single spacing a toc?
with regards to including eplain text, why not typesetting it as a separate document, and then do something
\externalfigure[eplaintoc.pdf][width=\textwidth,height=\t extheight]
Hans
Thanks for the reply. When I run the regular Context TOC macros I get a wide space, equivalent to a blank line, between chapters. It is of course entirely possible that I have done something wrong in setting the TOC up. Here are some pertinent extracts from my main file: ---------------------------------- -- John Culleton Able Typesetters and Indexers http://wexfordpress.com
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
At 22:00 05/05/2004, you wrote:
On Wednesday 05 May 2004 02:07 am, Hans Hagen wrote:
At 18:40 05/05/2004, you wrote:
using the Eplain macros. If there is a way to single space the TOC using the regular Context macros I will be happy to eliminate the Eplain, which may solve some of the other problems.
what is single spacing a toc?
with regards to including eplain text, why not typesetting it as a separate document, and then do something
\externalfigure[eplaintoc.pdf][width=\textwidth,height=\t extheight]
Hans
Thanks for the reply. When I run the regular Context TOC macros I get a wide space, equivalent to a blank line, between chapters. It is of course entirely possible that I have done something wrong in setting the TOC up. Here are some pertinent extracts from my main file:
\setuplist[chapter,section][before=,after=]
![](https://secure.gravatar.com/avatar/8b3c344f0adba6016612e05447039f44.jpg?s=120&d=mm&r=g)
On Wednesday 05 May 2004 02:07 am, Hans Hagen wrote:
At 18:40 05/05/2004, you wrote:
using the Eplain macros. If there is a way to single space the TOC using the regular Context macros I will be happy to eliminate the Eplain, which may solve some of the other problems.
what is single spacing a toc?
with regards to including eplain text, why not typesetting it as a separate document, and then do something
\externalfigure[eplaintoc.pdf][width=\textwidth,height=\t extheight]
Hans
This answer put me on the path to a solution of another problem. I had an order form made up of two text blocks with a table in the middle. It compiled fine so long as I left the main body of my document out. When I brought body.tex in to the run then the table portion started giving errors. So I set up a special run which generated just that page in a pdf file. However I didn't want to shrink it as Hans suggested, and Context doesn't usually cater to a full-page graphic nor does it let one pick an origin point as such. I finally found a way to move the origin point and then brought the pdf into the page. I fooled with \inmargin, \rput (pstricks), \kern,\leftskip and about half the commands in the plain tex vocabulary. Here is a solution that works, bringing in a page size graphic and placing it properly on my page: \startstandardmakeup[doublesided=yes] \vglue -1in \hglue -.65in\externalfigure[order.pdf] \stopstandardmakeup This has broader potential for assembling multiple pdf pages into a single document. The glue sizes are of course document dependent. -- John Culleton Able Typesetters and Indexers http://wexfordpress.com
![](https://secure.gravatar.com/avatar/8b3c344f0adba6016612e05447039f44.jpg?s=120&d=mm&r=g)
All of my problems of this moment are solved. there is an oddity however that can be noted. I use a master file and call components into it with \input statements. If I put the \stoptext statement at the end of the main file I get an extra page or sometimes two pages at the end of the run. If however I demote the \stoptext statement to the end of the last file included the spurious page disappears. -- John Culleton Able Typesetters and Indexers http://wexfordpress.com
![](https://secure.gravatar.com/avatar/8b3c344f0adba6016612e05447039f44.jpg?s=120&d=mm&r=g)
On Wednesday 05 May 2004 07:12 pm, Matthew Huggett wrote:
John Culleton wrote:
...
I use a master file and call components into it with \input statements....
Is there any advantage to using a master file with \input statements compared to using ConTeXt project and component files? Or are these totally different things?
Matt __
They are mostly different in usage. I have a single document, a book, and I find it convenient to subdivide it into files. For example I carry the same macro set from job to job, modifying it with each successive use. It saves a lot of typing. And as recently illustrated if an error crops up I can turn off segments of the document for debugging purposes. In an authoring situation I may further subdivide the body component into chapters. This allows me to write the book in non-consecutive pieces and even rearrange it for different markets etc. for example I have a file http://wexfordpress/tex/shortlist.pdf that is really a chapter to a never-completed book. I have never explored the project/component structure of Context. My one-person shop does not need sophisticated project management. I am not authoring works but typesetting the work of others. In a shop concerned with document creation, and perhaps multiple authors, the Context project management features would be worth another look. For me they are more bother than they are worth. I collect all the files for a job in one directory (folder) and that is it. Each job is different, so commonality is served by copying over the master or "book" file as well as some useful files like fonts.tex and macros.tex to the new job folder. The surname of thecustomer is the folder name. After many years as a management analyst, systems analyst and so on I have decided that simpler is better. One should have enough controls, enough structure, but no more than enough. Also, and this is an important point, I work in pdftex and even plain TeX as well as Context. My master file technique is generic to all these. Finally, I think Hans assumed too much of his readers (or at least this reader) when he wrote the passage on project etc. control. I read it but still ask myself "what is the cost vs. benefit" and "how does it work in the day to day world"? But that would take a book by itself, and there are more important topics to be addressed in Context documentation. -- John Culleton Able Typesetters and Indexers http://wexfordpress.com
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
At 23:34 06/05/2004, you wrote:
I have a single document, a book, and I find it convenient to subdivide it into files. For example I carry the same macro set from job to job, modifying it with each successive use. It saves a lot of typing. And as recently illustrated if an error crops up I can turn off segments of the document for debugging purposes.
\component and \environment also work outside the structure there's also \readfile{filename}{}{} all these commands, except \input, obey path and subpath rules - search test.tex on ./test.tex ../test.tex ../../test.tex - search on (predefined) <pathlist>/<subpathlist>/test.tex
Finally, I think Hans assumed too much of his readers (or at least this reader) when he wrote the passage on project etc. control. I read it but still ask myself "what is the cost vs. benefit" and "how does it work in the day to day world"? But that would take a book by itself, and there are more important topics to be addressed in Context documentation.
it depends, for big manuals i always use'm an advantage is that one can for instance process components without the need to include all environments explicitly since they are taken from th eproduct / project files Hans
participants (3)
-
Hans Hagen
-
John Culleton
-
Matthew Huggett