Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sun, 11 Sep 2005 12:10:14 +0200
From: Simon Pepping <spepping@leverkruid.nl>
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Space-resolution doesn't work
Message-ID: <20050911101013.GA4716@oranjetip.leverkruid.nl>
Mail-Followup-To: fop-dev@xmlgraphics.apache.org
References: <Pine.LNX.4.62.0509091354320.29316@malatesta.cs.unibo.it>
 <20050910195456.GC5644@oranjetip.leverkruid.nl>
 <20050911110256.0323.DEV@jeremias-maerki.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050911110256.0323.DEV@jeremias-maerki.ch>
User-Agent: Mutt/1.5.9i

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
> > >                  |
> > >     +------------+------------+
> > >     |            |            |
> > > BlockLM 1    BlockLM 2    BlockLM 3
> > >                  |
> > >           +------+-----+
> > >           |            |
> > >       BlockLM A    BlockLM B
> > > 
> > > BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the 
> > > elements representing its block content, without any space.
> > > 
> > > In order to decide which elements it has to create, the outer BlockLM 
> > > could have some lines like:
> > > 
> > > (currentChild = BlockLM 1
> > >  nextChild = BlockLM 2)
> > > 
> > > space1 = currentChild.getSpaceAfter();
> > > space2 = nextChild.getSpaceBefore();
> > > if (this.mustKeepTogether()
> > >     || currentChild.mustKeepWithNext() && !nextChild.hasBreakBefore()
> > >     || !currentChild.hasBreakAfter() && nextChild.mustKeepWithPrevious) {
> > >     // there cannot be a break between the two children,
> > >     createElementsForSpace(resolve(space1, space2, false, false));
> > > } else {
> > >     // there can be a break between the children
> > >     createElementsForSpace(resolve(space1, null, false, true),
> > >                            resolve(null, space2, true, false),
> > >                            resolve(space1, space2, false, false));
> > > }
> > 
> > This is a good idea. 
> 
> I agree.
> 
> > Each LM would invoke this whenever it steps from
> > one child to another. Only the top level LM would also invoke it for
> > its before and after edges.
> > 
> > I would think of a different treatment of the spaces (space specifiers):
> > List spaces = new List(currentChild.getSpacesAfter(),
> >   nextChild.getSpacesBefore());
> > createElementsForSpaces(spaces);
> 
> Good idea, too. I actually wondered how to implement Luca's suggestion
> and I ended up subclassing Knuth classes (in my mind for now) to hold
> the additional space specifier info, but this is a much cleaner approach
> even if a little more objects might be instantiated here. I'll try to
> document this on the Wiki once I'm through playing through my examples
> so I really understand every aspect of the topic.

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 advantage is that it fits in with the existing
getNextKnuthElements, and the LMs can calculate their spaces when they
are calculating their Knuth elements, like they do now.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl