On 02.03.2005 17:05:55 Glen Mazza wrote:
> Yes, I'm not in Simon's league here--I know very
> little about TeX--so I'll defer to you two on this
> issue.
I'm also still struggling. :-)
> Just try to make sure that the final algorithm
> will help us support the keep-* properties.
Yes, the algor
Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue. Just try to make sure that the final algorithm
will help us support the keep-* properties.
Thanks,
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Thanks. I think this has only to do
Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the rules
I'm unsure here. My interpretation comes from two
places:
1.) Section 4.8, the last paragraph of [1]:
"The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep condit
Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.
I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If
Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified. Am I correct here? And, if so, is what
you're planning going to result in an algorithm that
will help us do this?
Thanks,
Glen
--- Jere
I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks.
--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> >
> > As for the plan to implement a new page-breaking
> mechanism: I've got to
> > do it now. :-) I'm sorry if this may put some
> pressure on some of you.
> > I'm also not sure if I'm fit already to tackle it,
> but I've got to
> > do it anyway.
Jeremias Maerki wrote:
Hi Jeremias,
I finally have Knuth's "Digital Typography" and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that "bes
On 01.03.2005 22:25:12 Simon Pepping wrote:
> On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> > Jeremias Maerki wrote:
> >
> > > processing time and additional memory requirements. This
> > > leads me to the question if we shouldn't actually implement
> > > two page-breaking stra
On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > processing time and additional memory requirements. This
> > leads me to the question if we shouldn't actually implement
> > two page-breaking strategies (in the end, not both right
> > now). For a speed
On Tue, Mar 01, 2005 at 03:02:38PM +0100, Jeremias Maerki wrote:
> As for the plan to implement a new page-breaking mechanism: I've got to
> do it now. :-) I'm sorry if this may put some pressure on some of you.
> I'm also not sure if I'm fit already to tackle it, but I've got to
> do it anyway. Si
Jeremias Maerki wrote:
> processing time and additional memory requirements. This
> leads me to the question if we shouldn't actually implement
> two page-breaking strategies (in the end, not both right
> now). For a speed-optimized algorithm, we could even think
> about ignoring side-floats.
Right here: http://nagoya.apache.org/eyebrowse/[EMAIL
PROTECTED]&by=thread&from=984205
On 21.02.2005 01:15:41 Renaud Richardet wrote:
> Jeremias,
>
> > I went back to Simon's and Finn's ideas about page breaking and I see
> > some overlap.
>
> could you point me to where Simon and Finn exposed
Jeremias,
> I went back to Simon's and Finn's ideas about page breaking and I see
> some overlap.
could you point me to where Simon and Finn exposed their ideas?
thanks, Renaud
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
run for, say, 20 iterations and, at that time, assume an
infinite loop and throw an Exception to break the cycle?
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 3:56 AM
To: FOP
Subject: Re: Page breaking infinite loop
On Wed, 2002-09-1
AM
To: FOP
Cc:
Subject: Re: Page breaking infinite loop
On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
>
> By the way .. any comments
On Wed, 2002-09-18 at 20:38, Christian Geisert wrote:
> Go for it! (don't forget to assign the bug to yourself)
>
> By the way .. any comments from you (as a classloader expert ;-)
> on the following bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10255
If you want to fix that bug why n
g pinned down, I can work on that instead. I really just want to put my
effort where it's needed
I'm not sure when I became a classloader expert, but I won't complain. ;)
-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 18, 2002
Rhett Aultman schrieb:
> I'm having a very involved working weekend this weekend, and I'm writing my list of
>things to do. There's some openings in it, and I thought I might tackle the infinite
>loop that occurs in the page breaking test as has been documented in some previous
>bugs in our Bu
29 matches
Mail list logo
