Re: Attempt to make KOMA-Script style & OptimizePages troubles

[Valeriy E. Ushakov]

On Fri, Jun 09, 2000 at 01:00:33 +0200, Matej Cepl wrote:

> I have tried even @OptimizePages option and the result is highly
> unsatisfactory (Table of Contents broken in middle of page, 

@OptimizePages records some data during a run and then uses that data
on the next run.  Table of contents is missing during first run, since
no data for it was available.  Then on the next run data for TOC are
available and all of a sudden :-) a big chunk of text appears at the
begining of document thus effectively invalidating data saved by
@OptimizePages on the previous run.

[Here you might catch me and say that TOC comes out broken after the
*third* run, not the second.  See below.]

Just run it one more time @OptimizePages is sensitive to changes in
the document and I believe User's guide suggests that it should be
avoided until you're done with content and should be tried only when
you start polishing of the final look.

Incidentally, this reminded me of an interesting wart in Lout.
Consider a simple report with, say, a footnote.  Run lout afresh once
- now all the data for TOC are stored in the database.  Run it the
second time - oops no TOC.  What the heck - you might ask, the first
run have made TOC data available.

The answer is surprisingly simple.  When database index is written,
Lout assignes a number to every symbol it writes out.  Now consider
lout.li file from the first and from the second runs:

First run:

    00symbol 19 @BasicSetup @DocumentSetup @FootNote
    00target 20 @BasicSetup @DocumentSetup @ContentsPlace

Second run:

    00symbol 20 @BasicSetup @DocumentSetup @FootNote
    00target 19 @BasicSetup @DocumentSetup @ContentsPlace

On the first run there were no galleys in the db waiting to attach to
@ContentsPlace, so @FootNote was "seen" before @ContentsPlace.  On the
second run lout notes, that some galleys are wating for @ContentsPlace
and thus it is "seen" before @FootNote.

So on the first run galleys were written out for symbol #20 but now
@ContentsPlace is symbol #19, so galleys and target can't find each
other and you need one more run for them to meet.

So for your document:

Run 1:
    TOC data are written

Run 2:
    TOC is not produced, because of the bug described above

Run 3:
    TOC *is* produced, thus shifting things down and invalidating
    data @OptimizePages collected on the previous run

Run 4:
    This time TOC is in place and @OptimizePages data should be fine.


> and some widows/orphans remaining including in section headlines).

Huh?  Widows and orphans are single lines left on the preceding page
or carried over to the next page.  Section title reserves space of 3f
right below itself, so that there's a room for the section body to fit
on the same page.  I don't understand how a section title could be
*split* over between pages.

Perhaps I just don't understand that part of your question.

I formatted you sample article and (after four runs) it seems ok.

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen