Simon, thanks for looking into this. I'm not quite sure I got your
instructions for a "markers5c" right. I'd appreciate if you'd check in the
test case you created.
I've added a Bugzilla item [1] for this. I intend to revisit this later.
It would really be good to have test cases for all those n
Jeremias,
I have looked into the problem in more depth. The wrong retrieved
marker is not only due to the bogus area, but also to the flawed logic
of dealing with retrieve-position for the markers in
PageViewport.addMarkers. Even if block 5 adds a bogus area to page 1,
block 5 would not qualify fo
Finn Bock wrote:
> I would pass the element on the immidiate parent, which recursively
> passes them on the top-level LM in the direction. For inline, the
> toplevel would be LineLM and for blocks it would be the PageLM.
Ok, I misunderstood what you wrote, now I think we were saying the same
thin
Finn Bock wrote:
> Not at all. It is a rather trivial change to knuth to pick a
> page break when there is N pages of lookahead.
>
> If we assume that finished page knuth element arrive one at
> time to the KnuthPage algorithm, the main loop becomes:
>
> addKnuthElement(element) {
> if el
[The Web Maestro]
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 resource
The Web Maestro wrote:
> 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
Yes, there is another side, and I r
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 Knut
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 t
On Feb 7, 2005, at 7:21 AM, Luca Furini wrote:
Finn Bock wrote:
Using your description as a jumping point, here is my ideas for page
breaking. I suppose it is even more pie-in-the-sky since I haven't yet
written anything about it.
As I have been doing a few experiments about page breaking, I'm happ
[Luca]
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
outer block
|
-
| |
innerinner
blockblock
12
In order to decide whether there c
Finn Bock wrote:
>Using your description as a jumping point, here is my ideas for page
>breaking. I suppose it is even more pie-in-the-sky since I haven't yet
>written anything about it.
As I have been doing a few experiments about page breaking, I'm happy to
join in this conversation.
>The alg
Simon Pepping wrote:
I do not have much time to look into your problem, so I will just try
to give a quick answer.
In my view the current BP setup is not able to generate good page
break decisions. It only can do a first-fit algorithm. From your
account, BPs are also overloaded to signal the comple
Simon,
I'm sorry that I missed your plan. I didn't remember your posting this.
I think your plan would be a good start into refactoring the breaking in
block progression direction. I think it'll need to be clarified WRT
resets/backtracking in case of final decisions on page break, column
handling
Jeremias,
I do not have much time to look into your problem, so I will just try
to give a quick answer.
In my view the current BP setup is not able to generate good page
break decisions. It only can do a first-fit algorithm. From your
account, BPs are also overloaded to signal the completion of a
OK...I see its purpose now. But please put in a
descriptive comment for isBogus() in
AbstractLayoutManager so others down the road
understand what it means and what it is for.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen,
>
> no, I'm afraid the isBogus() method is necessary
> bec
Glen,
no, I'm afraid the isBogus() method is necessary because it checks the
parent LM. In the markers6a.xml example (for which I still have to write
the checks, I just found out), the block in the third cell of the fifth
row has an effective BPD of 0 and therefore fits nicely into the
available s
Jeremias,
I don't see the need for the bBogus variable/isBogus()
method, because in the three or four places where the
value of this variable is actually *being used*, it is
just set to :
bBogus = !bp1.generatesAreas();
So it appears you can just rely on
"!bp1.generatesAreas()" in these places
Can't add much here, but I do remember noticing the
bogus areas being created when I was trying to fix
spacing about a year ago. And, yes, I do agree it
would be better if our algorithms did not need them to
be created.
Thanks,
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I've got a po
I've got a possible fix for the problem. But I don't know if it's not
too much of a hack. At least it somehow feels like a hack. Any comments
about the attached patch? Obviously, some javadocs are missing and the
naming could probably be improved but this is just an idea how this
could be fixed.
I
Team,
I've just checked in markers5a and markers5b which look very closely
which marker is added to which page for every block.
As I'm still somewhat in the process of getting to know the layout
engine I don't have a quick answer to that although I'm making progress
in understanding. Here's what
20 matches
Mail list logo
