Re: Synchronization questions

2004-01-31 Thread Peter B. West
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

Re: Synchronization questions

2004-01-31 Thread Peter B. West
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

RE: Synchronization questions

2004-01-31 Thread Andreas L. Delmelle
-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,

Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
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

Re: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread J.Pietschmann
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

Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Simon Pepping
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

RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Andreas L. Delmelle
-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

RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
-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

Re: Updating licenses

2004-01-31 Thread Jeremias Maerki
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

RE: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Glen Mazza
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: -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

DO NOT REPLY [Bug 17999] - @border in fo:block : overwrites area page margin

2004-01-31 Thread bugzilla
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 [Bug 17999] - @border in fo:block : overwrites area page margin

2004-01-31 Thread bugzilla
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.

RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
-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

Re: [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

2004-01-31 Thread Peter B. West
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

Re: Updating licenses

2004-01-31 Thread Peter B. West
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

cvs commit: xml-fop/src/java/org/apache/fop/area BlockContainer.java BlockArea.java ReferenceArea.java

2004-01-31 Thread pbwest
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

cvs commit: xml-fop/src/java/org/apache/fop/area TransformMatrix.java

2004-01-31 Thread pbwest
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

Re: Synchronization questions

2004-01-31 Thread Peter B. West
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