Forgive the response to my own post...

Clay Leeds wrote:
Peter B. West wrote:

Victor Mote wrote:

Peter B. West wrote:


These are interesting and important issues.  I had no notion of the HZ
algorithm, but I was dimly aware from my reading as a teenager of the
"rivers" problem, and acutely conscious of its distracting effect from
my reading.  In my thinking about layout, I have been conscious of the
need to be able to evaluate such issues at a high level.  The only way
such an evaluation can be done is by layout look-ahead.  The page must
be laid out before "rivers" can be assessed.  (Finding them would be an
interesting problem in itself - and no doubt part of HZ.)



It actually would seem to go beyond look-ahead, and instead be more along
the lines of laying the content out multiple times & scoring each one.


True, but I had in mind that any such approach will be built on the fact that any layout is, in some sense, tentative. Rhett raised the question some time ago of a means recording (and scoring) intermediate results, something which will be an essential element of such a solution.

At this stage, I would tend to think not of doing every possible layout, but of following the "optimum" values to perform initial layout, and then testing the result for "goodness". The minimum-maximum range provides the slack - within the context of the spec - for applying whatever other set of layout tuning algorithms that FOP implements.

I would see these being arranged as a set of heuristics - for want of a better word - that are applied in a structured fashion to detected layout conflicts of particular types. What comprises a conflict would be determined by those configurable parameters.

In the initial version, we only need to provide for the most basic of these, as long as the mechanism is general enough to allow for refinement.

Does the idea that there would be intermediate results mean that a "human" could determine which is the best to perform the final layout? I'm thinking of a system similar to how some OCR programs enable the user to contribute to the process of recognition when the OCR program has problems determining a word or character. (FYI: OCR=Optical Character Recognition--used in scanning text-based documents which are converted to text for archiving, indexing, etc.).

If so, could the implementation offer some way of "saving" the best method? I would think it would work like a userconfig file.
I meant to add my reasoning. Since one can assume that generating multiple iterations will be processor intensive, if there existed some sort of "config" file identifying clues as to how the hz algorithm should proceed for a particular file, it would shorten the processing time, as well as ensure that the output was always the same.

--
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to