On Tue, 13 Sep 2005 04:25 pm, Jeremias Maerki wrote:
FYI, I'm going to try reimplementing the whole space-resolution part
on the block-progression-dimension (to start with) using the inputs
from both Luca and Simon and based on my findings I've documented in
the Wiki:
FYI, I'm going to try reimplementing the whole space-resolution part on
the block-progression-dimension (to start with) using the inputs from
both Luca and Simon and based on my findings I've documented in the
Wiki:
http://wiki.apache.org/xmlgraphics-fop/SpaceResolution
I've started by creating a
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM
On Sun, Sep 11, 2005 at 11:19:38AM +0200, Jeremias Maerki wrote:
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
I like it!
On 11.09.2005 12:10:14 Simon Pepping wrote:
snip/
An alternative procedure is this: Let each LM return spaces together
with the Knuth elements in getNextKnuthElements. At a higher level,
the returned list is scanned for consecutive lists of spaces, which
are then resolved. The
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
I think we need to revisit the whole space-resolution story. The current
code is fine for only the simplest of cases. If you look at the 4.3.1
Space-resolution Rules in the spec the example given there shows quite
clearly IMO that we probably can't just rely on the right combination of
Knuth
Jeremias Maerki wrote:
I'll start from scratch to come up with a better strategy of
implementing these rules. I'll probably start by documenting a few cases
in the Wiki and try to develop the right element list for them. After
that I'll try to find out who exactly to implement everything.
