On Feb 7, 2005, at 11:57 AM, Victor Mote wrote:
The Web Maestro wrote:
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the Knuth system
is more 'expensive' in terms of resources, we could make
non-Knuth the default, and enable Knuth via a config file.

Hi Clay:

The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).

Thanks for the heads up, and also for the 'clue'... I never completely understood what happened, as it occurred before I was committed. ;-) I understand a bit more, thanks to this e-mail... I suspect there may be another 'side' to the story--there always is--and that there's may be other contributing factors... but this helps me understand much more than I understood before. Your explanation below also helps! I probably just need to ask for help when I don't understand something... but I've got enough going in my head anyway...

FOP-DEV... Please don't take this as griping (it's not!), but I get lost in thee BP/BPD/IPD/AT speak now and again, which is one reason I tend to stay out of the fray on that stuff. If I get confused--and choose to attempt to contribute to a discussion--I'll speak up about anything that strikes my fancy. If there's something I don't get... I'll search Google first.

BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.

To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time. I am a little confused about whether FOP's design will
even allow that to happen right now. I understood both Keiron's and Finn's
design ideas (and Peter West's also) to be releasing pages from the AreaTree
long before a page-sequence was even completely parsed. However, I may have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody knows that
status of that effort or how to find his out-of-print books, please let us

Might these links help:




The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. That may
be sub-optimal, but it is my best guess right now about a reasonable way to

Victor Mote

Thanks again for the explanation! Cheers!

Web Maestro Clay
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Reply via email to