t-fit.
>
> If the IPD 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 start
t; total-fit and best-fit or maybe even first-fit.
If the IPD 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
aring 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 of time.
How short?
--
Peter B. West <http:/
ay 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?
>
>
g 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 wit
Jeremias Maerki wrote:
>Would you consider sharing what you already
>have? This may help us in the general discussion and may be a good
>starting point.
Ok, I'll try to.
The main change in the LineLM is that the line breaking algorithm does not
select only the node in activeList with fewest dem
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. in a
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:
>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
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 pag
orming 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 on your normal
> phone via SkypeOut if you don't have
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 Tu
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
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
> strateg
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
fulfil
a first-fit strategy at all. If
> we're really going down
> the two-strategy path we'll probably end up with a
> best-fit strategy 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
>
s-fop/PageLayout
On 02.03.2005 14:48:17 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 pla
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,
ed 8 weeks. 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 i
--- 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
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 glanc
ty
cheap to call to the Netherlands. 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-bre
gs 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.
>
> I do not have a broadband connect
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 actua
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, no
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, b
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
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
I would be please to listen.
Renaud
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 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
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.
>
>
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
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
w
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
27; in terms 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 tha
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
[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
would not mind if someone else
would implement it.
Hi Simon,
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.
The algorithm that the PageLM uses are a slightly modified knut
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 som
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. B
50 matches
Mail list logo
