On 02.03.2005 17:05:55 Glen Mazza wrote:
> Yes, I'm not in Simon's league here--I know very
> little about TeX--so I'll defer to you two on this
> issue.
I'm also still struggling. :-)
> Just try to make sure that the final algorithm
> will help us support the keep-* properties.
Yes, the algor
Yes, I'm not in Simon's league here--I know very
little about TeX--so I'll defer to you two on this
issue. Just try to make sure that the final algorithm
will help us support the keep-* properties.
Thanks,
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Thanks. I think this has only to do
Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the rules
I'm unsure here. My interpretation comes from two
places:
1.) Section 4.8, the last paragraph of [1]:
"The area tree is constrained to satisfy all break
conditions imposed. ***Each keep condition must also
be satisfied***, except when this would cause a break
condition or a stronger keep condit
Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.
I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If
Just a sanity check here, the XSL specification seems
to suggest always the first-fit strategy for page
breaking *except* where keeps are explicitly
specified. Am I correct here? And, if so, is what
you're planning going to result in an algorithm that
will help us do this?
Thanks,
Glen
--- Jere
I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks.
--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> >
> > As for the plan to implement a new page-breaking
> mechanism: I've got to
> > do it now. :-) I'm sorry if this may put some
> pressure on some of you.
> > I'm also not sure if I'm fit already to tackle it,
> but I've got to
> > do it anyway.
ion and I can confirm
invoices and insurance policies are a common use case for XSL-FO. A lot of
companies have performance as a priority and we have no one using side floats
or even thinking about using them, so optimizing for speed by ignoring side
floats sounds like a good idea! But this is
On 01.03.2005 22:25:12 Simon Pepping wrote:
> On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> > Jeremias Maerki wrote:
> >
> > > processing time and additional memory requirements. This
> > > leads me to the question if we shouldn't actually implement
> > > two page-breaking stra
On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > processing time and additional memory requirements. This
> > leads me to the question if we shouldn't actually implement
> > two page-breaking strategies (in the end, not both right
> > now). For a speed
On Tue, Mar 01, 2005 at 03:02:38PM +0100, Jeremias Maerki wrote:
> As for the plan to implement a new page-breaking mechanism: I've got to
> do it now. :-) I'm sorry if this may put some pressure on some of you.
> I'm also not sure if I'm fit already to tackle it, but I've got to
> do it anyway. Si
Jeremias Maerki wrote:
> processing time and additional memory requirements. This
> leads me to the question if we shouldn't actually implement
> two page-breaking strategies (in the end, not both right
> now). For a speed-optimized algorithm, we could even think
> about ignoring side-floats.
I finally have Knuth's "Digital Typography" and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that "best-fit" is probably
the obvious strat
gzilla/show_bug.cgi?id=31699
[PATCH] Performance improvement in property consumption.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
[Peter]
Alt-design just uses a sparse array, constructed at END_ELEMENT. Space
savings are progressively realized as the depth of the FO Tree reduces.
Maximum consumption occurs at the points of greatest depth of the
tree, minima at the end of each page-sequence.
[me]
IIRC your sparse array does
Peter B. West wrote:
Finn Bock wrote:
[Peter]
Alt-design just uses a sparse array, constructed at END_ELEMENT. Space
savings are progressively realized as the depth of the FO Tree reduces.
Maximum consumption occurs at the points of greatest depth of the
tree, minima at the end of each page-seque
Original Message
Subject: Re: [Fwd: Re: Performance improvement in property consumption.]
Date: Fri, 15 Oct 2004 18:30:39 +1000
From: Peter B. West <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Finn Bock wrote:
On Oct 15, 2004, at 1:02 PM, Finn Bock wrote:
[Clay]
Which of the alignment-* property is the one you're referring to that
has been implemented?
I was just looking at them from the point of view of the property
subsystem, where only "baseline-shift" has been implemented. I didn't
mean to imply t
[Clay]
Which of the alignment-* property is the one you're referring to that
has been implemented?
I was just looking at them from the point of view of the property
subsystem, where only "baseline-shift" has been implemented. I didn't
mean to imply that it actually work all the way through layou
Clay Leeds wrote:
When I look at the FOP Compliance page, I see a couple of items which
are implemented (I assume this page is in reference to the
0_20_2-maintain CVS branch--I am I correct in this assumption?).
Hi Clay - yes compliance page does refer to 0.20.5 functionality.
Chris
On Oct 15, 2004, at 12:05 AM, Finn Bock wrote:
In the rest of the elements, the set of fields matches the spec. The
only exception is a bug where the some of the inline LayoutManagers
uses "vertical-align" which is a shorthand. The layoutmanagers should
instead use the properties that the short
eviously stored are now stored
in the FObj.
So if PropertyList can be thought of as a C-like
struct holding the values of its FObj's properties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.
But, obviously, given the performa
Thanks for your explanation Finn. (Also thanks Peter
and Andreas for taking the time to respond--I read
through both your messages quite carefully as well, in
order to better understand the property resolution
issues involved.) I looked at the current code and
the patch again, and I think I now h
Don't mind the delay. Too many email addresses in a futile attempt to
keep one spam-clean. Apologies to Christian.
Original Message
Subject: Re: Performance improvement in property consumption.
Date: Thu, 14 Oct 2004 08:29:24 +1000
From: Peter B. West <[EMAIL PROTEC
In my proposal the specified and the cached properties are still stored
in the property list but only the relevant properties are retained in
the fo object.
[Andreas]
Yes, and IIJC, at the same time, you're eliminating the need for downstream
property queries having to be performed through the Prop
Keep in mind that there is 2 different sets of
properties:
- The set of specified properties.
- The relevant properties (as listed in the spec
under each element).
The existing PropertyList stores the specified
properties in the super
HashMap and has an additional cache which stores all
retrieved
nslation of the captured lists of attributes to the already
instantiated FOBj's 'properties' --in the sense of instance variables--, and
because storing the props in instance vars eliminates the need for
inter-FObj communication through the PropertyList, it speeds up the process
downst
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> [Glen]
>
> > Why is it more efficient (I know it is, given your
> > metrics, but want to know why)--aren't you just
> moving
> > the values already stored in the PropertyList into
> > separate fields in the FO objects? Yes, you're
> > releasing the Pr
as a C-like
struct holding the values of its FObj's properties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.
No, see above.
But, obviously, given the performance/memory boost
you're noting, PropertyList *can't* be regarde
roperties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.
But, obviously, given the performance/memory boost
you're noting, PropertyList *can't* be regarded as a
C-like struct. Why? Could PropertyList be made more
efficient i
[Glen]
All fo elements are required to
extract all the
properties that they need and to store the values as
instance fields in
the fo element.
I love the performance boost you're recording but have
a philosophical issue of an "fo object needing a
property"--it is really
g/bugzilla/show_bug.cgi?id=31699
>
> The performance increase is 42% while at the same
> time using %27 less
> memory.
...
> All fo elements are required to
> extract all the
> properties that they need and to store the values as
> instance fields in
> the fo e
Hi Team,
I've put together another largish patch that changes the way properties
and used by the FO objects, the layout managers and the FOEventHandler
subclasses.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31699
The performance increase is 42% while at the same time using %27
gzilla/show_bug.cgi?id=31699
[PATCH] Performance improvement in property consumption.
--- Additional Comments From [EMAIL PROTECTED] 2004-10-13 10:41 ---
Created an attachment (id=13071)
Unified diff
gzilla/show_bug.cgi?id=31699
[PATCH] Performance improvement in property consumption.
Summary: [PATCH] Performance improvement in property consumption.
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Se
On Fri, 2004-02-20 at 15:46, J.Pietschmann wrote:
> *bg*
> Twenty years ago, I had to work on a 8008 driven computer
> with 4k RAM and 12k ROM. That's enough to run a program
> which nicely prints formatted and justified text (25 lines
> a 80 characters). We went a lng way since then.
I went
John Austin wrote:
Isn't allocation the only unseen part of construction ? Everything
else is visible in the code and surely a few assignments are never
expensive. Any other expensive operations will stand out in
measurements of code execution.
That's correct. However, the article seemed to shout "
On Thu, 2004-02-19 at 17:53, J.Pietschmann wrote:
> John Austin wrote:
> > I noticed this artcle on Developer Works:
> >
> > Java theory and practice: Garbage collection and performance
> > http://www-106.ibm.com/developerworks/library/j-jtp01274.html
> >
John Austin wrote:
I noticed this artcle on Developer Works:
Java theory and practice: Garbage collection and performance
http://www-106.ibm.com/developerworks/library/j-jtp01274.html
Something to read on Thursday.
Nice read, however, they don't talk about constructors. There
are still argu
I noticed this artcle on Developer Works:
Java theory and practice: Garbage collection and performance
http://www-106.ibm.com/developerworks/library/j-jtp01274.html
Something to read on Thursday.
--
John Austin <[EMAIL PROTECTED]>
Finn Bock wrote:
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches
at different times. While building the subtree of any node, all of
the properties are maintained in a HashMap, along with a BitSet of
specified properties.
When the subtree construction is c
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet of specified
properties.
When the subtree construction is complete, the Hash
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> If I mentioned PropertyValue singletons, it was a slip of the fingers.
> I maintain Property singletons, which are exist solely to provide access
> to certain "static" information about individual properties.
>
Don't
[me]
1) Only store the specified properties. That is what HEAD does now.
2) Put the relevant properties in a fast Property[] array and the
remaining specified properties in a HashMap. For fo:root the result
would be an array of size 1 for the 'media-usage' property.
3) Expect to store every
The beauty of the
approach is that it simplifies the logic, without (I hope) costing too
much in performance.
In terms of the re-layout, re-parsing is not required (Re, re, re your
boat...) IndirectValues will need to be re-evaluated in the new
context, but the process of re-layout is not ma
On Tue, 2004-01-13 at 20:49, Glen Mazza wrote:
> Let's not get too certain of anything right now with
> respect to implementation--but you probably have a
> point--a huge and very repetitively formatted document
> (say, the Chicago phone book, perhaps) would have
> comparatively fewer properties wi
Let's not get too certain of anything right now with
respect to implementation--but you probably have a
point--a huge and very repetitively formatted document
(say, the Chicago phone book, perhaps) would have
comparatively fewer properties with a higher
cardinality for each.
Glen
--- "Andreas L.
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> OK--this may also be overkill then. Thank you for the
> analysis.
>
It will prove useful, I am sure --provided we want to uphold the intention
to be able to process any size of document (from sources that may not be as
) a reference to
> an
> > already-created one. So, indeed, only one
> instance of
> > that font-size = "12pt" would need to be created.
>
>
> The amount to be saved will of course depend on the
> input, but for
> "DocBook: The Definite Guide"
ocBook: The Definite Guide", the amount is quite small. So small that
I didn't bothered to do it when I made the performance patch.
Here is a break down on the string values that are parsed into
properties. It is the output from "sort | uniq -c | sort" so in the
first column is
Sorry for the long post... Just trying to put a few ideas together.
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> Pardon me for repeating what might be obvious,
Well, it wasn't to me, so... thanks in advance
> but I'll like to take
> a look at what information we want to store at each FObj.
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> What I'm very concerned about, for example, are
> cases like tables, where it
> would be quite awkward to have the TableCell FObj's
> reference their own copy
> of a Property instance
To put it more precisely, the individual Properties of
an F
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > I.e., for all those references to the 'foo'
> property
> > instance for the children of an FO where that
> value
> > would be inherited, we don't have to create a new
> > Property instance, just a reference to the
> inherited
> > instance.
>
> Right, th
Finn Bock wrote:
[Glen]
One thing I'm missing here, for Finn's design below:
values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance
Can't we just have, say, values[1] refer to the
parent's Property instance in cases w
[Glen]
One thing I'm missing here, for Finn's design below:
values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance
Can't we just have, say, values[1] refer to the
parent's Property instance in cases where inheritance
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> One thing I'm missing here, for Finn's design below:
>
> values[0] = null // always null.
> values[1] = reference to a 'foo' Property instance
> values[2] = reference to a 'baz' Property instance
>
> Can't we just have,
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > -Original Message-
> > From: Finn Bock [mailto:[EMAIL PROTECTED]
> >
> > > [Andreas L. Delmelle]
> > > In this case, however, I think you
> > > can't fully 'push' these onto the descendants,
> as this would
> > > lead to absurd storag
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> > [Andreas L. Delmelle]
> > In this case, however, I think you
> > can't fully 'push' these onto the descendants, as this would
> > lead to absurd storage-reqs for quite average-sized documents.
>
> > OTOH, the inherited p
[Glen Mazza]
... what's your opinion on switching to FO
Constants at this time? They probably will not give
us the rate of return that property constants have;
but there may be future indexing or processing
advantages with them. I'm not strong one way or the
other on them.
Since then, you have r
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > 1.) For the new PropertyList constructor (in the
> patch), you appear to be
> > duplicating the element ID argument, once as "el",
> the other time
> > as "elementId"--just to confirm, they are
> referring to the same thing (and
> > hence one of them
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 13:45 ---
Further comments and discussions here:
http://marc.theaimsgroup.com/?l=fop-dev&m=107369978306013&w=2
http://marc.theaimsgroup.co
[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance
In the performance sensitive PropertyList.lookup(), the code doesn't
have to test for properties that are unknown by fo:bar
return values[ind
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> --- Additional Comments From [EMAIL PROTECTED] 2004-01-10
Glen / Finn,
Hope you don't mind my interrupting here:
Particularly this point I found interesting:
> 3.) PropertySets.java defines those properti
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 01:07 ---
Finn,
I'm now looking at the changes to PropertySets.java (already applied) and
PropertyList.java (only partly so) and have a few question
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-24 00:08 ---
"It does not get filled at all.
It is there to support an AFAICT unused feature in the foproperties.xml file
which makes it possible to spec
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-23 03:39 ---
Finn,
Oops, sorry--My recent check-in of property-sets.xsl--I forgot to give you
credit for that work. It was basically a renaming o
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-22 22:18 ---
It does not get filled at all.
It is there to support an AFAICT unused feature in the foproperties.xml file
which makes it possible to specify s
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-22 22:01 ---
Finn,
Question on the FOPropertyMapping.java class--from your changes, it is
dutifully filling up the s_htGeneric (property) HashMap from
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-16 12:14 ---
Excellent...Thanks for the explanation! I'll look over it tonight.
Glen
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-16 08:15 ---
The instances of java.util.BitSet that are created for each fo:element in
PropSets are only used for collecting the properties of that element a
Victor Mote wrote:
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions of
Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already
Peter B. West wrote:
> If we go towards integer representation, properties in the API will
> always be represented by integers. By looking at this particular
> signature, we are not locking ourselves in. We can add other signatures
> if the need arises, but they can be extensions of the basic ca
Victor Mote wrote:
Peter B. West wrote:
Victor Mote wrote:
Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
object creation, why create a MinOptMax object? Why not just return the
three resolved values in separate methods. Anything that uses the
information will have to s
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 21:59 ---
Finn,
Thanks for your explanation.
More questions--I've just generated the PropSets.java, but am not sure what
this is needed for.
1.) As
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> The previous posting seems to indicate that the
> properties have been
> decomposed, the chronologically latter posting seems
> to indicate that the
> shorthand retains its shorthand character.
I think Peter and I were talking about inner-to-FO
propert
Peter B. West wrote:
> Glen Mazza wrote:
> > --- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> >
> >>See above. In alt.design, all compounds are
> >>shorthands, and all
> >>shorthands are presumed to have been resolved into
> >>their components
> >>during FO Tree building.
> >>
> >
> >
> > BTW, do
Peter B. West wrote:
> Victor Mote wrote:
> > Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
> > object creation, why create a MinOptMax object? Why not just return the
> > three resolved values in separate methods. Anything that uses the
> > information will have to sepa
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 06:58 ---
The compound properties are shifted so that both base and compound can be
stored into a single int. In PropertyList there are several cases whe
Good thing I asked--I may need to do that with the
Constants interface, where the ordering is currently
alphabetical.
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
>
> It's in the ordering of the properties. There is a
> simply for loop to
> process properties (attributes, in fact) def
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 01:25 ---
I brought in the Constants information for a start, and will be continuing to
analyze the rest of your patch as well as Alt-Design until we're
Glen Mazza wrote:
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthan
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-14 23:02 ---
Finn,
The property constants file that your version will generate defines three
constants as follows:
// Masks
int COMPOUND_SHIFT = 9;
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
>
> See above. In alt.design, all compounds are
> shorthands, and all
> shorthands are presumed to have been resolved into
> their components
> during FO Tree building.
>
BTW, does Alt-Design already resolve the cases where
*both* a shorthand and
Victor Mote wrote:
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here, fortunate
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-14 02:24 ---
Looking at your patch currently...
Glen
J.Pietschmann wrote:
> If we are at it, I'd vote for dumping generating the property
> classes and check the java files into CVS.
+1. I have noted Finn's and Glen's subsequent objections, and Joerg's
subsequent comments. I agree that the general need for that level of
flexibility has passed, and
Peter B. West wrote:
> > It would be really nice to have a getLeaderLength()
> > which returns a MinOptMax. this means the getLeaderLength()
> > has:
> > - resolve percentages and functions
> > - deal with the leader-length shorthand setting before this
> > - deal with inheritance (n/a here, fo
t think that this proposition
rushes me (were you waiting on me for something?). I have the least
knowledge of or interest in the performance side. Having said that, I *very*
much want us to implement a lowest-common-denominator,
it-will-never-matter-what-the-guts-look-like API for the FO Tree
I like the generation process as it allowed me to try out and
experiment with different optimizations. I don't think that I
realisticly could have added caching of compound properties or changed
the abs2rel/rel2abs code if I had to change the Maker classes manually.
[J.Pietschmann]
If its commo
Glen Mazza wrote:
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the XS
I haven't looked at the XSLT code but I have a question
in my mind that I need to answer about it.
I wonder what it is that is being generated and what were
the design alternatives to the codegen implementation.
One question that popped in to my head was:
Is there 'missing polymorphism' here ?
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the XSLT files--suggests
Finn Bock wrote:
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of compound properties or changed the abs2rel/rel2abs
code if I had to change the Maker classes manually.
If its commo
+1 to that, but please don't dump the original XML files
(foproperties.xml etc.) because they could come handy later.
Besides that, I can't contribute much to this discussion, but I am
confident that you guys find a good solution. The "integer idea" sounds
reasonable to me and I'm particularly gla
[J.Pietschmann]
[snip]
If we are at it, I'd vote for dumping generating the property
classes and check the java files into CVS.
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of com
xsl-fo DTD.
In addition to the performance improvements,
I suggested before we could have some form of
// very rough pseudocode
checkPropertySupported (int property) {
return isSupported[property];
}
That would be written like this:
boolean checkPropertySupported (int property) {
return
On the other hand a series of smaller adjustments to the property
handling has improved the total processing time about 10%.
[Peter B. West]
That's a better time improvement than I got with alt.design. The fact
that I have extra overhead from the pull parsing may account for that.
Perhaps, but it
1 - 100 of 258 matches
Mail list logo
