LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

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

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

Print Reply
Frank Mittelbach <[log in to unmask]>
Mon, 6 Oct 1997 22:36:24 +0100
text/plain (57 lines)
i really wonder why discussions always stick with one
subject. discussing mime advantages might be interesting but when i
scan my archives later for LaTeX journal classes finding all that
stuff under this heading ...

anyway

Sebastian Rahtz writes:
 >  > I looked at using it for TUGboat, but it didn't quite meet the
 >  > requirement, since regular issues of TUGboat run articles together on
 >  > the same page.  It would work OK for proceedings issues, but they're
 >
 > Barbara Beeton has talked about this often as well, and it always
 > seems to founder on the rock of changing document in mid page. you
 > wouldnt *think* it was so hard, would you?
 >
 > Perhaps some one with a fresh mind and some time to spare should take
 > up the cudgels and have another crack at \includex

it is not that hard but is it really worth the effort? it is hard
enough :-)

what you need to do is:

 1) capture the exact position on the page when some \includex file
ends; this means stretch and shrink etc

 2) capture the content info of all internal float lists, ie type of
   float size etc

then when you exclude some file you finish the current page (assuming
that start page of your exclusion is not equal end page of your
exclusion) then you start a new page in a what that you end up at
exactly the point as given by 1) (which is the real hard bit and which
will be wrong for a long time even after reading and reading output
routine chapter in the TeX book :-) and you make sure that your info
about 2) is used to replace the float lists.

and this is basically it.

only point is and David pointed this out already: how accurate is the
result? normally what you will produce is rubbish, any or nearly any
change in preceeding includes will make everything obsolete. this is
bad enough with the current \include but there in most cases it does
work reasonably well. but here?

what do you gain? you gain processing speed as you go along since you
can work from front to back and only process one include at a time
(unless you have forward references which change your earlier
material ....

so?

any takers?

frank

ATOM RSS1 RSS2