Simon Pepping wrote:
> On Fri, Jan 18, 2008 at 12:09:14AM +0100, Andreas L Delmelle wrote:
>> I have always somehow assumed there to be a threshold in the most common
>> cases. In the sense that certain (maybe in fact even the bulk of) feasible
>> breaks can already be excluded quite early, even
On Fri, Jan 18, 2008 at 12:52:01PM +0100, Luca Furini wrote:
>
> I was wondering whether this the promotion can be performed also each
> time the active node list contains just a single node ...
Yes, that should be possible.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
On Jan 18, 2008 12:20 PM, Vincent Hennebert
<[EMAIL PROTECTED]> wrote:
> Andreas L Delmelle wrote:
>
> > I have always somehow assumed there to be a threshold in the most common
> > cases. In the sense that certain (maybe in fact even the bulk of)
> > feasible breaks can already be excluded quite
On Fri, Jan 18, 2008 at 12:09:14AM +0100, Andreas L Delmelle wrote:
> I have always somehow assumed there to be a threshold in the most common
> cases. In the sense that certain (maybe in fact even the bulk of) feasible
> breaks can already be excluded quite early, even if the sequence consists
Andreas L Delmelle wrote:
> On Jan 17, 2008, at 20:57, Simon Pepping wrote:
>
>> On Thu, Jan 17, 2008 at 12:27:11AM +0100, Andreas L Delmelle wrote:
>>>
>>> The lower-level LMs can signal an interrupt to the ancestor LMs,
>>> based on
>>> information they get through the LayoutContext --forced bre
On 18.01.2008 00:09:14 Andreas L Delmelle wrote:
> On Jan 17, 2008, at 20:57, Simon Pepping wrote:
>
> > On Thu, Jan 17, 2008 at 12:27:11AM +0100, Andreas L Delmelle wrote:
> >> Right now, the element list is constructed as the result of
> >> recursive calls
> >> to getNextChildLM.getNextKnuthEl
Andreas L Delmelle schrieb:
Yet another way to look at it: the result of a total-fit strategy is the
best-fit for the entire page-sequence, which can be viewed as the result
of multiple total-fits for subsets of the page-sequence, especially
where forced page-breaks are involved. If we place a
On Jan 17, 2008, at 20:57, Simon Pepping wrote:
On Thu, Jan 17, 2008 at 12:27:11AM +0100, Andreas L Delmelle wrote:
Right now, the element list is constructed as the result of
recursive calls
to getNextChildLM.getNextKnuthElements().
/The/ return list upon which the page breaker operates is t
On Thu, Jan 17, 2008 at 12:27:11AM +0100, Andreas L Delmelle wrote:
> Right now, the element list is constructed as the result of recursive calls
> to getNextChildLM.getNextKnuthElements().
> /The/ return list upon which the page breaker operates is the one that is
> ultimately returned by the Fl
On Jan 16, 2008, at 20:32, Simon Pepping wrote:
On Wed, Jan 16, 2008 at 01:20:36AM +0100, Andreas L Delmelle wrote:
So, on top of that, I'm thinking of making b) less of a monolithic
process.
At the moment, we always wait for an endPageSequence() call on the
AreaTreeHandler, which works fi
On Jan 16, 2008, at 08:38, Jeremias Maerki wrote:
Hi Jeremias
On 16.01.2008 01:20:36 Andreas L Delmelle wrote:
At the moment, we always wait for an endPageSequence() call on the
AreaTreeHandler, which works fine for small to medium-sized page-
sequences, but is definitely not scaleable to la
On Wed, Jan 16, 2008 at 01:20:36AM +0100, Andreas L Delmelle wrote:
>
> So, on top of that, I'm thinking of making b) less of a monolithic process.
> At the moment, we always wait for an endPageSequence() call on the
> AreaTreeHandler, which works fine for small to medium-sized page-sequences,
>
On 16.01.2008 01:20:36 Andreas L Delmelle wrote:
>
> Hi people,
>
> I know I've mentioned it a few times before, so here's another
> attempt at brainstorming about possible improvements in interaction
> between fotree and layoutengine.
> (So, obviously what follows does not apply to the outpu
13 matches
Mail list logo
