> > And this doesn't even have too much to do about paragraph rebreaking.
> > In a typical case of paragraph spanning two pages with differing
> > column widths, you'd need to make up the box the paragraph has to fit
> > in with the bottom part of it having the width of column on the next
> > page, and the top part having the width of the current page's column.
> > But even that is not so trivial, since you need to do that just after
> > the previous paragraph has been committed to the output, and the next
> > one is about to be typeset...
>
> What's wrong with breaking the whole thing with width 10cm, shipout the
> first part and put everything left back on the to-do list? Right: It's
> already partially 'digested'. But nowadays there's no reason not to work
> only on a single paragraphs' worth of data, we could scan the entire
> document seeral times - or at least pretend we do. Every compiler does.
> this when running the preprocessor...
I guess that for paragraphs to look nice one needs to have a flexibility.
There are two approaches that for sake of completeness and "user preference
matters" should be available:
1. ("yours") Break the paragraph at width1, shipout what fits, treat the rest
as an (almost) new paragraph and break it again at width2
2. ("mine") If a paragraph's box doesn't fit on one page, prepare a new box
with arbitrary shape (i.e. part of it width1, part of it width2) and rebreak,
then ship the first part to page1 and another part to page2.
I guess it all reduces to having a capability of (1) rebreaking "what's left"
and (2) having boxes with any shape without tricks. Note that (2) doesn't
need to be terribly complicated - although one could extend the "basic"
typesetter with additional ways to specify box shapes (a.k.a. writing new C++
classes), it all boils down to the "box shape" being able to return the
"fitting" rectangular box at given range of vertiacal coordinates, and to do
it at various tolerances of "badness", so that borderline cases would be
handled gracefully like TeX does.
In any event, it should be a reasonable thing to expect the "new" TeX-alike
thing to be able to generate exactly the same output as DEK's TeX, given
reasonably same source. I.e. all of TeX's font handling, paragraph breaking
and paragraph-between-pages breaking algorithms should be fully implemented,
same goes for dimensions. That way, if one properly translates DEK's TeXbook
source into TeXalike source, it will yield same output and the positions of
glyph boxes in the output will be same.
I think that proper use of C++ will make the coding much more pleasant than in
WEB.
Cheers, Kuba
