Unnesting properties and makers.

Hi, After updating from CVS, it is most likely necessary to do an "ant clean" to get rid of the old generated maker classes, before building. I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. I've found an argument for unnesting

Re: Unnesting properties and makers.

Finn Bock wrote: I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. I think you could leave the file there for now. It should be sufficient to inactivate the related task in the buildfile (for example putting it in an XML comment). D

Re: Unnesting properties and makers.

I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. [J.Pietschmann] I think you could leave the file there for now. Ok. It should be sufficient to inactivate the related task in the buildfile (for example putting it in an XML comm

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > Hi, > > After updating from CVS, it is most likely necessary > to do an "ant > clean" to get rid of the old generated maker > classes, before building. > Great job--the build is now only 604 classes--1/3 removed! This simplification does make the prop

Re: Unnesting properties and makers.

Finn Bock wrote: I have not yet removed the properties.xsl file from CVS. I guess it should be removed since it isn't used anymore. [J.Pietschmann] I think you could leave the file there for now. Ok. It should be sufficient to inactivate the related task in the buildfile (for example putt

Re: Unnesting properties and makers.

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: [Glen Mazza] Could you explain why we have the datatypes instances to begin

Re: Unnesting properties and makers.

Peter B. West wrote: > With my naive understanding of parsing as a two-stage process (lexemes > -> higher level constructs) I have been curious about earlier comments > of yours about multi-stage parsing. Can ANTLR do this sort of thing? I'm not quite sure whether you mean by "parsing as a two-sta

Re: Unnesting properties and makers.

Finn Bock wrote: ...--I believe, we do (frequently?) have more than one datatype per property, correct? I remember two cases, but I can only find one at the moment: In Title.setup(): Formally, there are a few more, for example initial-page-number. The code treats them as Java String. This prevents

RE: Unnesting properties and makers.

> -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > Does anybody know what "" means for line-height??? Know? I guess not. But judging from the spec... "XSL adds the following value with the following meaning: Specifies the minimum, optimum, and maximum values, the

Re: Unnesting properties and makers.

Andreas L. Delmelle wrote: Does anybody know what "" means for line-height??? Know? I guess not. But judging from the spec... Ah well, I overlooked this "XSL adds the following value with the following meaning: Specifies the minimum, optimum, and maximum values, the conditionality and preced

RE: Unnesting properties and makers.

> -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > > > Ah well, I overlooked this And it's easy to overlook. The spec-layout is quite misleading, putting this XSL-addition in the place it is now... If you're reading diagonally, it looks more like an insignificant n

RE: Unnesting properties and makers.

> -Original Message- > From: Finn Bock [mailto:[EMAIL PROTECTED] > > 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). >

RE: Unnesting properties and makers.

> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > LayoutProps, for example, is already present, but seems to be > underused at the moment.) > > Speaking of which: what exactly is the purpose of having a spaceBefore/spaceAfter in fop.traits.LayoutProps and anot

Re: Unnesting properties and makers.

J.Pietschmann wrote: Peter B. West wrote: > With my naive understanding of parsing as a two-stage process (lexemes > -> higher level constructs) I have been curious about earlier comments > of yours about multi-stage parsing. Can ANTLR do this sort of thing? I'm not quite sure whether you mean

Re: Unnesting properties and makers.

J.Pietschmann wrote: ... Well, one of the problems with the FO spec is that section 5.9 defines a grammar for property expressions, but this doesn't give the whole picture for all XML attribute values in FO files. There are also (mostly) whitespace separated lists for shorthands, and the comma sepa

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 interfac

Re: Unnesting properties and makers.

--- Finn Bock <[EMAIL PROTECTED]> wrote: > [Glen Mazza] > > > Could you explain why we have the datatypes > instances > > to begin with--what they're for? I'm not sure > what > > their precise purpose is. > > The datatypes are the slightly more complex property > values. The > property classes

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

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.

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.

--- 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: 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: 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.

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: 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.

[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.

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.

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.

> -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: 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.

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.

> -Original Message- > From: John Austin [mailto:[EMAIL PROTECTED] > > So I copied that program and ran it on my RH 9 system. > Hmmm... so you copied it with or without the c&p-error ;) > Got the following results. I am just quoting the results here: > > [EMAIL PROTECTED] foptest]$ java