--- 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]
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=26434.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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 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=26434.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Peter B. West wrote:
snip/
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
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
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
--- 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
Glen Mazza wrote:
Thanks for taking the time to explain Glen. What youve said is mostly as
I understood it. Some comments below.
snip/
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
-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
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
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
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 property
-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
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
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
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
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
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 -49
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
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
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.
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
34 matches
Mail list logo
