LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Carlisle <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 6 Oct 1997 20:24:22 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
Hans>   So, unless this is changed, I think 1 and 2 above are somewhat
Hans>   intertwined.

but my point was that for something of tugboat length why do you need
to \include (as opposed to \input) the separate articles. In that case
questions of separate aux files do not arise.

Other comments from Michael

> If you put each article in a group the save stack can take a serious
> hit
I had in mind to not group the articles, but to explicitly check that
certain document-critical things are not changed by one of the `sub documents'
eg if the page size or default font setup gets changed by one chapter
then complain loudly.

> Nevertheless imho they are troublesome enough that a better approach
> would be to set up a system of communicating between the different parts
> through an auxiliary file.

Ah. interesting. In general this would mean that the page break
calculations at the end of the article do not `see' what is coming up
in the next article, but TeX's page break lookahead is so pitiful
compared to its line break algorithm perhaps you are not losing so much.

> At the end of the first part, measure the
> actual depth of the last page and pass it to the next article, along
> with the current page number and whatever else is needed.

So this implicitly implies (I think) that no float will float into or
out of a region that may be \included. For sub articles that is
probably anyway what you want but people often seem to ask for a
general include system acting on arbitrary portions of the document
just as a technical convenience to avoid re-compiling every time.

> This means using an OS-specific script
or another cousin to docstrip and fontinst:-)

> Understood; but isn't it true that the floats will get printed in any
> case (in the next really included portion, or at \end{document})? The
> worst scenario that I can see is some floats from section 3 get printed
> in section 5 if the user didn't happen to include section 4 on this
> particular LaTeX run. Will this happen often enough in practice to
> really be a problem?

my point was that in a situation where the included files do not form
a logical `float boundary' (I think boom is the term used for oil slicks:-)
then if a float comes out of a section into the following part of the
document then if that section is not included on some run, the source
for the float is not available and so it is hard to see how to leave
the space for it in the later parts. If page breaks are not faithfully
reproduced there does not seem to be much point in an \include system
and you may as well use \input. (It would be possible for the aux file
to record the size of all pending floats at an \include).

I return to my original point. Most of the difficulties of \include
relate to \includeonly, ie the potential for *not* including certain
sections. The case of just wanting to `include' certain independent
units (but to include all of them) is not really directly related.

> take all the floats in \@toplist, \@botlist,
> \@deferlist and set them at the end of the preceding text as `here!'

yes some kind of \flushfloats command would be generally useful to put
at the end of sections, again independant of \include. I think I once
saw such a command. Chris? Donald Arseneau?, you?

> Isn't the main unsolved problem for \include making sure that non-immediate
> \write's go to the proper .aux file?

Pah, write then all to the main aux file (with a note to say which bit
they come from, if that is needed) (not that I've tried coding it that
way:-)

David

ATOM RSS1 RSS2