cvs commit: xml-fop/src/java/org/apache/fop/fo FONode.java

pbwest 2004/01/26 17:17:21 Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java Log: Added direct foTree reference, instead of relying on Tree reference in superclass. Revision ChangesPath No revision No

cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination FoLayoutMasterSet.java

pbwest 2004/01/26 18:04:03 Modified:src/java/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoLayoutMasterSet.java Log: Updated license to 2.0. Return unmodifiable Map finalPageSequenceMasters in place of HashMap pageSequenceMasters. Revision

cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination PageSequenceMaster.java

pbwest 2004/01/26 18:07:49 Modified:src/java/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design PageSequenceMaster.java Log: Updated license to 2.0. Revision ChangesPath No revision No revision 1.1.2.2

cvs commit: xml-fop/src/java/org/apache/fop/datastructs TNodeTest.java

pbwest 2004/01/26 15:20:18 Modified:src/java/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design TNodeTest.java Log: Changes to accommodate new TNode. Updates license to 2.0. Revision ChangesPath No revision No

cvs commit: xml-fop/src/java/org/apache/fop/fo FoRoot.java

pbwest 2004/01/26 17:59:10 Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FoRoot.java Log: Updated license to 2.0. Revision ChangesPath No revision No revision 1.1.2.9 +17 -49xml-fop/sr

cvs commit: xml-fop/src/java/org/apache/fop/fo FOTree.java

pbwest 2004/01/26 18:01:17 Modified:src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FOTree.java Log: Updated license to 2.0. Changed PreOrder arguments to match changes to Node. Revision ChangesPath No revision No

cvs commit: xml-fop/src/java/org/apache/fop/datastructs TNode.java

pbwest 2004/01/26 15:19:06 Modified:src/java/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design TNode.java Log: Changes to accommodate new Tree and Node. Updates license to 2.0. Revision ChangesPath No revision No

cvs commit: xml-fop/src/java/org/apache/fop/datastructs Tree.java

pbwest 2004/01/26 15:07:11 Modified:src/java/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design Tree.java Log: Removed references to modCount, used for ConcurrentModificationException detection. Removed references to the setting of the containing Tree

cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination FoPageSequenceMaster.java

pbwest 2004/01/26 18:06:53 Modified:src/java/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoPageSequenceMaster.java Log: Updated license to 2.0. Other tidying up. Revision ChangesPath No revision No

Re: Unnesting properties and makers.

Finn Bock wrote: [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x false method call 581 true method call 581 false instanceof 160 true instanceof 170 [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x false method call 1272 true method call 2304 false instanceof 17945 true instanceof 912 [/d

RE: Unnesting properties and makers.

On Mon, 2004-01-26 at 17:45, Andreas L. Delmelle wrote: > > -Original Message- > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > The result is then: > > > > [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x > > false method call 581 > > true method call 581 > > false instanceof 160 > >

Re: Unnesting properties and makers.

J.Pietschmann wrote: Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. Instanceof is exactly as fast as a simple function call after warm-up. That's very useful to know. instanceof has had a very bad press. Peter -- Peter B. West

RE: Unnesting properties and makers.

On Mon, 2004-01-26 at 17:45, Andreas L. Delmelle wrote: > > -Original Message- > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > The result is then: > > > > [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x > > false method call 581 > > true method call 581 > > false instanceof 160 > >

RE: Unnesting properties and makers.

> -Original Message- > From: Finn Bock [mailto:[EMAIL PROTECTED] > The result is then: > > [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x > false method call 581 > true method call 581 > false instanceof 160 > true instanceof 170 > > [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp

Re: Comments on the changes to the property subsystem

On Sun, Jan 25, 2004 at 11:38:14PM +0100, Finn Bock wrote: > [Simon Pepping] > > >I have just catched up with the massive changes to the property > >system. Allow me to share a few observations: > > Thanks for your comments. How do you otherwise think it compares to the > previous generated prop

Re: Unnesting properties and makers.

Finn Bock wrote: Instanceof is exactly as fast as a simple function call after warm-up. That is not what I remembered, [Snip] I'm surprised. I made some measurements with a JDK 1.3.0, with ~50 warm-up cycles to give HotSpot something to optimize, and vaguely remembered instanceof was slightly faste

Re: Unnesting properties and makers.

file:///d:/java/REC-xsl/slice6.html#fo_external-graphic [Andreas L. Delmelle] (Off-topic: Finn, I don't think I have access to your d:-drive ;) ) I hope not :-0 . Sorry about that. Yeah, if it make sense to add more groups of properties together (and it seems that such a ipd,bpd pair make sense)

Re: Unnesting properties and makers.

[Andreas L. Delmelle] public static void testInstanceOf(Prop prop) { for (int i = ITERS; i >= 0; i--) { boolean x = prop.getString() != null; } } public static void testCall(Prop prop) { for (int i = ITERS; i >= 0; i--) { boolean x = pro

RE: Unnesting properties and makers.

> -Original Message- > From: Finn Bock [mailto:[EMAIL PROTECTED] > > public static void testInstanceOf(Prop prop) { > for (int i = ITERS; i >= 0; i--) { > boolean x = prop.getString() != null; > } > } > > public static void testCall(Prop prop)

Re: Unnesting properties and makers.

Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. [J.Pietschmann] Instanceof is exactly as fast as a simple function call after warm-up. That is not what I remembered, so I made a small test program and ran it with 3 different versions of jdk: [/d/fop] /c/java/

Re: RTF: white-space-treatment and linefeed-treatment

Peter Herweg wrote: (2) I defer the processing of all inline-generating, text-containing FOs, and process them in RtfHandler.endBlock. I'd say start with this option, although I'm starting to believe we could and should move whitespace processing to before the invocation of the structure renderer's

Re: Unnesting properties and makers.

Glen Mazza wrote: Well, instanceof is slower I believe, but better self-commenting. Instanceof is exactly as fast as a simple function call after warm-up. J.Pietschmann

RE: Unnesting properties and makers.

> -Original Message- > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > [Andreas L. Delmelle] > > > Hmmm... coming back to my recent question about the use of/access to the > > background-color property: I somehow would feel much for > further extending > > the way the Common*Properties are

Re: PDF Transcoder patch

Glen Mazza wrote: Thanks for taking the time to explain Glen. What youve said is mostly as I understood it. Some comments below. The FOUserAgent is ultra-easy (?) to access from the FOP Application, but not-so-easy (and, also, not-so-relevant) for the PDFTranscoder. (We also have an SVGUserAg

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > > however, is probably preferable--the word > "Property" > > figures quite highly in the spec! Do you have a > > problem remaining with it? > > Not at all, it is just that I though it would be Good--we can stick with "Property" then. > > Indeed. Whic

Re: PDF Transcoder patch

Chris, Certain packages of our project--in this case, the "image" package--are used both by the PDFTranscoder (a separate application, if you will) and the FOP application. The FOUserAgent is ultra-easy (?) to access from the FOP Application, but not-so-easy (and, also, not-so-relevant) for the

RTF: white-space-treatment and linefeed-treatment

Hello, i am currently working on support for white-space-treatment and linefeed-treatment for the RTF module. Of course i don't want to reinvent the wheel, so i tried wanted Block.handleWhiteSpace method to do the job. But when i read the text data which is passed to RtfHandler.characters there i

Re: Changing policy on minimum JDK requirements for HEAD

Peter B. West wrote: The 0.20 series is supported on 1.3, so an important question is: what is the expected timeframe for availability of 1.4 for those users who are currently restricted to 1.3? Vendors should be able to provide their users with some indication of this. We should at least a

DO NOT REPLY [Bug 26434] - [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: PDF Transcoder patch

Glen Mazza wrote: I tried to do a complete switch from FOUserAgent to logger in the images package, was not able to (there are still other cases the FOUserAgent is actually being used.) Glen - I havent looked at this in detail, but my understanding of the FOUserAgent was the place holder for any

DO NOT REPLY [Bug 26434] New: - [PATCH] unnesting Property.Maker and rollling datatypes into thier properties.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Unnesting properties and makers.

Each of the Type classes also implements the get methods from Property so the layout must do exactly the same as it does now to extract the right value: propertyList.get(PR_INLINE_PROGRESSION_DIMENSION). getLengthRange().getOptimum().getLength(); [Andreas L. Delmelle] Hmmm...

Re: Unnesting properties and makers.

[Glen Mazza] I now understand what you're saying, and like the simplification you're suggesting. The current naming however, is probably preferable--the word "Property" figures quite highly in the spec! Do you have a problem remaining with it? Not at all, it is just that I though it would be co

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: Does anyone know why we wrap the datatypes instances in a property instance? I think we could avoid the property instance by having the datatypes extends an AbstractProperty class which implement a Property interface: public interface Property { pu