-Original Message-
From: John Austin [mailto:[EMAIL PROTECTED]
snip /
So I copied that program and ran it on my RH 9 system.
Hmmm... so you copied it with or without the cp-error ;)
Got the following results. I am just quoting the results here:
[EMAIL PROTECTED] foptest]$ java
--- 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 {
[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
Each of the typeType classes also implements the gettype 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]
--- 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. Which package should
-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 handled.
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
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]
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
public static void testInstanceOf(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop.getString() != null;
}
}
public static void testCall(Prop prop) {
[Andreas L. Delmelle]
snip /
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
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)
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
-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 . x
false
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
true instanceof
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
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
true instanceof
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
Andreas L. Delmelle wrote:
Does anybody know what space 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:
space
Specifies the minimum, optimum, and maximum values, the conditionality
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
snip /
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
-Original Message-
From: Finn Bock [mailto:[EMAIL PROTECTED]
snip /
Each of the typeType classes also implements the gettype methods
from Property so the layout must do exactly the same as it does now to
extract the right value:
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
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
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 by
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
--- 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
--- 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 wraps the
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-stage
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
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
snip /
Does anybody know what space means for line-height???
Know? I guess not. But judging from the spec...
XSL adds the following value with the following meaning:
space
Specifies the minimum, optimum, and maximum
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
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
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
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).
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
--- 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 properties
34 matches
Mail list logo
