as page breaking has not yet started.
The check could be done before starting the layout phase: if there is a
change, 2) is used, otherwise 1).
Maybe, the check could be even more sophisticated: for example, if the
first page is different, but the following are equally wide, we could use
2
changes, I fear 2) must be necessarily used: if a block is
split between pages with different ipd, only a few lines need to be
recreated.
Using 1), the LineLM should know how wide the lines are, but this cannot
be known as page breaking has not yet started.
The check could be done before starting
and recalculation of vertical boxes.
Of course, if it's possible to stay with one page-breaking algorithm for
all use cases that would be best (because of the reduced effort), but
only if the algorithm is reasonably fast for invoice-style documents.
I'm repeatedly confronted with certain speed
.
My problem is that I have to deliver working page breaking with keeps,
breaks, multi-column, adjustable spacing etc. in a relatively short
period of time.
How short?
Peter
--
Peter B. West http://cv.pbw.id.au/
Project Folio http://defoe.sourceforge.net/folio/
Jeremias
you already
have? This may help us in the general discussion and may be a good
starting point.
My problem is that I have to deliver working page breaking with keeps,
breaks, multi-column, adjustable spacing etc. in a relatively short
period of time.
How short?
--
Peter B. West http://cv.pbw.id.au
:
I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
Simon in the Netherlands than to call someone in Lucerne via PSTN.
Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page breaking either Sunday evening or next Monday or Tuesday
Jeremias Maerki wrote:
Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page breaking either Sunday evening or next Monday or Tuesday
somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
are Simon, Finn and Luca. I'm happy to call either of you
Sounds very interesting. Would you consider sharing what you already
have? This may help us in the general discussion and may be a good
starting point.
My problem is that I have to deliver working page breaking with keeps,
breaks, multi-column, adjustable spacing etc. in a relatively short
period
Jeremias Maerki wrote:
Sounds very interesting. Would you consider sharing what you already
have? This may help us in the general discussion and may be a good
starting point.
My problem is that I have to deliver working page breaking with keeps,
breaks, multi-column, adjustable spacing etc
I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
Simon in the Netherlands than to call someone in Lucerne via PSTN.
Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page breaking either Sunday evening or next Monday or Tuesday
somewhere
On Thu, Mar 03, 2005 at 08:34:54PM +0100, Jeremias Maerki wrote:
I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
Simon in the Netherlands than to call someone in Lucerne via PSTN.
Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page
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 best
--- 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. Since I don't
. So there's almost no chance that alt-design is repeated,
especially since the basic LM infrastructure will not be altered big
time and it looks like we are all going in the same direction for the
new page-breaking. It's clear that it has to be done and it seems to be
moveing in the direction
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
Glen Mazza wrote:
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
and
a total-fit or best-fit plus look-ahead. (See
Simon's list [1]) But
that's something we still need to figure out
together.
If we ever have multiple page-breaking options, it can
be a user-defined configuration switch. No problem
there.
Glen
[1]
http://wiki.apache.org/xmlgraphics-fop
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
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 below if we accept a lot
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 algorithm
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 best-fit is probably
the obvious strategy
To speed things up could we hold a conference (using Skype, for example)
to discuss further details on page-breaking? I'd volunteer to sum up any
results during that discussion for the archives. I have Finn on my Skype
radar already.
Jeremias Maerki
I would be please to listen.
Renaud
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
On Tue, Mar 01, 2005 at 03:09:46PM +0100, Jeremias Maerki wrote:
To speed things up could we hold a conference (using Skype, for example)
to discuss further details on page-breaking? I'd volunteer to sum up any
results during that discussion for the archives. I have Finn on my Skype
radar
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. Since
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 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 strategies
. According to the FAQ this is
possible.
On 01.03.2005 22:26:50 Simon Pepping wrote:
On Tue, Mar 01, 2005 at 03:09:46PM +0100, Jeremias Maerki wrote:
To speed things up could we hold a conference (using Skype, for
example)
to discuss further details on page-breaking? I'd volunteer to sum up
any
I'm at a point now where I run against a wall whatever I look at to do
next. I wanted to put off the page breaking issue as long as possible to
give myself more time to understand all the implications. It turns out
that this wasn't such a bad idea because I got a lot of hints along the
way where I
Right here: http://nagoya.apache.org/eyebrowse/[EMAIL
PROTECTED]by=threadfrom=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
of resources, we could make
non-Knuth the default, and enable Knuth via a config file.
Yes indeed. But without measurements I would guess that knuth page
breaking would be far less expensive than the knuth line breaking. The
line breaking has to deal with far more elements and because of that a
far larger
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
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
thing
[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
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
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 terms
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
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
, 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-18 at 20:38, Christian Geisert wrote:
Go
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 from you (as a classloader expert
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 Bugzilla. Before I settled
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
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 2:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Page breaking infinite loop
Rhett Aultman schrieb:
I'm
44 matches
Mail list logo
