> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> 1.0's bookmarks are different from 0.20.5's, the former has
> fox:bookmarks as the "parent" element.
> It's been that way in 1.0 for a long time,
> before I came on board I believe.
>
Yes, and it even has been discussed
- Original Message -
From: "Andreas L. Delmelle" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 14, 2004 2:58 PM
Subject: RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination
Root.java
> > -Original Message-
> >
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
Ignore this thread. Found the answer in the archives...
Sorry for the nuisance.
Greetz,
Andreas
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> Hope the use of the bookmarks extension wasn't meant to be
> changed in HEAD.
Oops. Just noticed that a Bookmarks class has been added to the extensions
package...
What's going to be the prescribed usage patte
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
Hi,
> Modified:src/java/org/apache/fop/fo/pagination Root.java
> Log:
> changed 'bookmarks' to 'outline' to avoid ValidateException for
> bookmarks extension
>
Hope the use of the bookmarks extension was
I guess I'm the guilty one here--but I have the
tabbing option shut off in JEdit, I'll be more careful
(and test at home what is happening.)
Sorry/Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
> jeremias2004/09/23 03:04:36
>
> Modified:src/java/org/apache/fop/area
> StorePagesModel.java
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> PageLayoutManager has a seed for multithreading; it
> implements
> Runnable. The idea is to let each page sequence run
> in its own
> thread. It has not been worked out.
I'm uncertain of its benefit (that which calls FOP
should do the multithreadi
On Tue, Sep 07, 2004 at 08:47:07PM +0200, Jeremias Maerki wrote:
>
> Question to everyone: We currently don't have a multi-threaded design
> like Peter West's approach. Can anyone think of a reason that all the
> FO-building and layouting process for one processing run may run within
> more than o
I reverted it to the original recursive method, this
appears to be the best compromise for everyone's
wishes.
Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> >>> A (farfetched) argument against ThreadLocals
> would be that they
> >>> prevent one FOP processing run to occur
> recursively du
A (farfetched) argument against ThreadLocals would be that they
prevent one FOP processing run to occur recursively during another
independent processing run. Like an extension element that itself
will attempt to process another fo document.
[Glen]
I think that restriction is implicit in the XS
Jeremias Maerki wrote:
On 07.09.2004 21:11:09 Finn Bock wrote:
[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run withi
I've done that already. It wasn't so much work but I had to get rid of
the Avalon Fortress container first. It still uses the Avalon
Framework, though.
That's how it works: There's a sample configuration file in
test/java/org/apache/fop/threading that shows how to configure the MT
testbed. The fil
My preference would be to explicit pass the shared data (in this case
the FOEventHandler) to the classes that needs it. If the recursion Glen
discovered is deemed too slow, then store the FOEventHandler in an
instance field for each FONode.
[Jeremias]
My preference, too. But having too much in F
On 07.09.2004 21:11:09 Finn Bock wrote:
> [Jeremias Maerki]
>
> > Question to everyone: We currently don't have a multi-threaded design
> > like Peter West's approach. Can anyone think of a reason that all the
> > FO-building and layouting process for one processing run may run within
> > more th
[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
de
On 07.09.2004 00:20:18 Glen Mazza wrote:
> Jeremias Maerki wrote:
>
> >On 06.09.2004 22:31:24 Glen Mazza wrote:
> >
> >
> >>Jeremias Maerki wrote:
> >What is an application in your terminology? I don't think there is such
> >a thing in Java. At least it's not a technical term but only a logic
Jeremias Maerki wrote:
On 06.09.2004 22:31:24 Glen Mazza wrote:
Jeremias Maerki wrote:
Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHand
On 06.09.2004 22:31:24 Glen Mazza wrote:
> Jeremias Maerki wrote:
>
> >Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
> >TreeBuilder is instantiated per processing run. The FOEventHandler is
> >set on FONode's static variable during startDocument(). The
> >FOEventHandler keeps tra
Jeremias Maerki wrote:
Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which
To be a bit more positive and not just criticizing, this could probably
be solved using a ThreadLocal [1] which would make the whole thing
almost as handy as a normal static variable but thread-safe. But I've
never done this myself, yet, so I can't talk out of experience. Just an
additional 0.05 CH
Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which are all relevant to one
Please elaborate.
Jeremias Maerki wrote:
I'm sorry, Glen, but I think you will have to revisit that one. If I'm
not absolutely wrong, this will break multi-threading capabilities.
On 06.09.2004 20:28:17 gmazza wrote:
gmazza 2004/09/06 11:28:17
Modified:src/java/org/apache/fop/fo FONode
I'm sorry, Glen, but I think you will have to revisit that one. If I'm
not absolutely wrong, this will break multi-threading capabilities.
On 06.09.2004 20:28:17 gmazza wrote:
> gmazza 2004/09/06 11:28:17
>
> Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
>
vmote 2003/08/15 23:43:51
Modified:src/java/org/apache/fop/apps Driver.java
src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
FObjMixed.java PropertyManager.java XMLObj.java
src/java/org/apache/fop/fo/flow InstreamForeignObj
pietsch 2003/06/26 17:16:28
Modified:src/java/org/apache/fop/fo/pagination Root.java
Log:
Test commit from Eclipse: removed unused import.
Revision ChangesPath
1.3 +3 -5 xml-fop/src/java/org/apache/fop/fo/pagination/Root.java
Index: Root.java
===
vmote 2003/03/25 15:34:11
Modified:src/codegen foproperties.xml
src/java/org/apache/fop/fo FOText.java FObjMixed.java
PropertyManager.java TextInfo.java
src/java/org/apache/fop/fo/pagination Root.java
Log:
Add support for text-t
26 matches
Mail list logo
