Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
I've been hacking the tree methods in Node recently
...
Are you talking 'maintenance vs. HEAD' here?
No. I realise the message was ambiguous. I was talking about versions
of my general
Peter B. West wrote:
This would be the clean way to express the current version of the code.
However, I am still toying with the idea of allowing (sub)trees to
synchronize on an object passed in as a parameter to the Node
constructor. If the object reference is null, synchronization is turned
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
snip /
It also occurred to me that optional synchronization might be a good
idea, allowing a common synchronization object to be passed to the Node
constructor. An alternative was to allow optional synchronization,
Tried the following type of FO-document:
- one page-sequence with a sort of TOC, a fo:table with basic-links to
detail-blocks
- multiple page-sequences, one for each detail-block
In the test document, the TOC is about five pages, containing links to +/-
300 detail-blocks. The detail-blocks all
Andreas L. Delmelle wrote:
In 0.20.5 this works very fine... In HEAD strangely the document is layed
^
laid :-)
out such that the first TOC page ends up
On Mon, Jan 26, 2004 at 11:32:22AM -, [EMAIL PROTECTED] wrote:
This patch is intended as inspiration and as an example of the discussion found
here:
http://marc.theaimsgroup.com/?l=fop-devm=107511296910230w=2
The patch includes the following:
- unnests the Property.Maker
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
snip /
All in all I think that this change simplifies the code, and would be
a good change.
Allow me to make some notes:
1. Would it not be a good idea to move Property.java from fo to
properties?
A question
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Andreas L. Delmelle wrote:
In 0.20.5 this works very fine... In HEAD strangely the
document is layed
^
laid :-)
Ahem... Sorry 'bout that.
out such that the first TOC page ends up after the last
Very cool! I did the whole thing manually back when I exchanged the
illegal short licence with the long one.
But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1
It looks like the {YEARS} marker seems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17999.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
I don't understand the problem. Could you trim it down to two
detail blocks,
and post the FO (assuming the trimmed down FO still
Simon Pepping wrote:
I have the following considerations:
1. The old situation has pure datatypes, which in theory may be reused
in other situations. In practice, these datatypes are very much
bound to properties, so that reuse is not realistic, and does not
happen in FOP code. Combining
Jeremias Maerki wrote:
Very cool! I did the whole thing manually back when I exchanged the
illegal short licence with the long one.
But I noticed the following:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/area/inline/InlineArea.java?rev=1.2.2.1
It looks like the
pbwest 2004/01/31 21:47:38
Modified:src/java/org/apache/fop/area/inline Tag:
FOP_0-20-0_Alt-Design InlineArea.java
InlineContainer.java
src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
pbwest 2004/01/31 21:49:10
Modified:src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
TransformMatrix.java
Log:
Fixed Copyright years.
Varioable name changes to match type name.
Revision ChangesPath
No revision
No
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
...
I was worried about increasing the probability of deadlock by having
many more locks held concurrently. Without having thought about it a
great deal, it seems to me that it is easier to
17 matches
Mail list logo