Peter B. West wrote:
The topic at hand is what API is needed for the FO Tree to be
able to pass
property values to its clients.
Ok. The trouble is that the relationship between FO Tree and Area Tree
is, for me, still very much an unresolved question. When we start
talking about these
Peter B. West wrote:
Yes, this is the real issue.
Only one of the real issues, I'm afraid.
OK, what are the others?
The thorns that immediately stick in my finger are
The topic at hand is what API is needed for the FO Tree to be able to pass
property values to its clients.
1)
Peter B. West wrote:
4) Managing the association out-of-line areas (footnotes and floats)
with the FONode/Area in which it was defined and the higher-level areas
(e.g. before-float-reference-area, footnote-reference-area,
main-reference-area) which are juggled as a result of the lower-level
J.Pietschmann wrote:
Footnotes are basically float-after areas. Both float before and footnotes
are not much of a problem except for multi column layout (and, well, in
tables). In multi-column layouts, the equal width of the column should
allow reassigning content after decreasing column height
Victor Mote wrote:
Peter B. West wrote:
...
The topic at hand is what API is needed for the FO Tree to be able to pass
property values to its clients.
Ok. The trouble is that the relationship between FO Tree and Area Tree
is, for me, still very much an unresolved question. When we start
Victor Mote wrote:
Peter B. West wrote:
...
Yes, this is the real issue. Since an fo:marker's content can be used more
than one place, this requires that its contents be grafted into the tree
where needed.
I think the only trick here is to pass the static content context back to
the get method so
Victor Mote wrote:
Peter B. West wrote:
2% of what? Of a reference area. Of what actually gets laid out on a
page. If a single flow object gets laid out over more than one page,
that reference may vary, but nothing changes in the FO Tree. It makes o
sense to second-guess the Area tree within
J.Pietschmann wrote:
Victor Mote wrote:
This is a good question. The answer to the first part is that it should
return an int, representing the number of millipoints. When it cannot be
resolved, it should return an int constant TBD_LAYOUT (or whatever),
which
is equal to -32,987 (or whatever).
Peter B. West wrote:
Good question. Make it
font-size=12pt+2%+0.8*(from-parent(height) div 32) though.
O well, the perils of staying awake late...
This is why I was talking some time ago about a PropertyValue type which
is an RPN-style expression, which can be rapidly resolved without
recourse
Peter B. West wrote:
What about font-size=12pt+2%+0.8*from-parent(height div 32) ?
Good question. Make it
font-size=12pt+2%+0.8*(from-parent(height) div 32) though. Even
nastier is
font-size=12pt+2%+0.8*(from-nearest-specified(height) div 32)
because in markers and in static-content, we
J.Pietschmann wrote:
Peter B. West wrote:
This is why I was talking some time ago about a PropertyValue type which
is an RPN-style expression, which can be rapidly resolved without
recourse to the general parser.
I'm not quite sure what the intend of this sentence is.
The maintenance branch
On Thu, 2003-11-27 at 13:58, Victor Mote wrote:
...
Again, this is an implementation detail, and doesn't affect the interface.
However, on the implementation side, it seems that the tradeoff will be
between doing a full parse each time, or creating lots of objects. John
Austin's inquiry about
Glen Mazza wrote:
Sent: Wednesday, November 26, 2003 3:17 PM
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] Properties API
--- Victor Mote [EMAIL PROTECTED] wrote:
The current implementation might look like this:
public class FObj {
public int getMaxWidth
John Austin wrote:
I am critical of what I percieve to be a pathological growth of objects
(and search times). If those problems are corrected, there are plenty of
resources left to do a few extra parses.
How often will you encounter expressions this complex ? Rarely.
If they become common
Peter B. West wrote:
Where does
repeated evaluation of the parse tree occur? Is there a parse tree object?
The necessary classes are somewhat distributed across the
packages. Some necessary classes are in fop.datatypes, the
common property superclasses are in fop.fo, with fop.fo.Property
being
On Thu, 2003-11-27 at 14:57, Victor Mote wrote:
John Austin wrote:
I am critical
Now, if you can figure out how to digest an FO document without building a
tree that represents a page-sequence object, I hope you'll share it with the
rest of us. That could be a breakthrough indeed.
I am
John Austin wrote:
I am critical of what I percieve to be a pathological growth of objects
(and search times). If those problems are corrected, there are plenty of
resources left to do a few extra parses.
How often will you encounter expressions this complex ? Rarely.
A complex expression tree
Victor Mote wrote:
John Austin wrote:
What I infer of the Tree structures in your discussion and Peter's
code suggests to me that FOP creates a DOM-ish view of the document
in one or more trees. This is a mis-match with the SAX parser that
is in there somewhere.
FOP's design on the SAX/DOM
Victor Mote wrote:
Peter B. West wrote:
What about font-size=12pt+2%+0.8*from-parent(height div 32) ?
Good question. Make it
font-size=12pt+2%+0.8*(from-parent(height) div 32) though. Even
nastier is
font-size=12pt+2%+0.8*(from-nearest-specified(height) div 32)
because in markers and in
Peter B. West wrote:
What about font-size=12pt+2%+0.8*from-parent(height div 32) ?
Good question. Make it
font-size=12pt+2%+0.8*(from-parent(height) div 32) though. Even
nastier is
font-size=12pt+2%+0.8*(from-nearest-specified(height) div 32)
because in markers and in static-content, we
--- Victor Mote [EMAIL PROTECTED] wrote:
validateValidProperty(int propVal)
{
return (supportedProps[propVal] == 1);
}
(Come to think of it, we can probably keep
validateValidProperty() in the FObj base class
alone
as well!)
IOW (I assume) use a 2-dimensional array, the
Victor Mote wrote:
FOP Developers:
This has been kicked around recently, but I realized that it may be
beneficial to go ahead and propose a change to get things going. The issue
of how Properties are stored in the FO Tree is in play. Since we now have FO
Tree pretty well isolated, I see some
--- Peter B. West [EMAIL PROTECTED] wrote:
The set of property values relevant to a
particular FO are
available in a sparse array, accessible by the int
index corresponding
to the Property.
Which source file has the enumerations of the
properties--I'd like to see how you listed them.
Glen Mazza wrote:
A few more ideas:
(1.) You may find that most of the properties that
need to be pulled out of the renderers and layout are
actually Area Tree object traits, so renderers
layout will probably also benefit from having the Area
Tree having these types of accessor functions.
--- Victor Mote [EMAIL PROTECTED] wrote:
Makes sense. I always like to let the compiler do
the work for me, so I
would probably first make all of the Property stuff
private, recompile, and
start fixing compile errors.
Oh...the smoke 'em out! style of programming! I
enjoy that too...
On Wed, 2003-11-26 at 14:45, Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
The set of property values relevant to a
particular FO are
available in a sparse array, accessible by the int
index corresponding
to the Property.
Which source file has the enumerations of
Peter B. West wrote:
depend on the type supported by the Property. Take MaxWidth. What
value will be returned? An int, representing the number of millipoints?
An Integer? A Length object? What happens when the width is, as
yet, unresolved, because it depends upon the resolution of the
Victor Mote wrote:
This is a good question. The answer to the first part is that it should
return an int, representing the number of millipoints. When it cannot be
resolved, it should return an int constant TBD_LAYOUT (or whatever), which
is equal to -32,987 (or whatever). So, the Area Tree or
--- Victor Mote [EMAIL PROTECTED] wrote:
The current implementation might look like this:
public class FObj {
public int getMaxWidth() { //WARNING
-- unchecked or tested!!
return
properties.get(max-width).getLength().getValue();
}
A subclass that
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
The set of property values relevant to a
particular FO are
available in a sparse array, accessible by the int
index corresponding
to the Property.
Which source file has the enumerations of the
properties--I'd like to see how you
Glen Mazza wrote:
--- Victor Mote [EMAIL PROTECTED] wrote:
The current implementation might look like this:
public class FObj {
public int getMaxWidth() { //WARNING
-- unchecked or tested!!
return
properties.get(max-width).getLength().getValue();
}
A subclass
I've read your proposal with great interest. I still have to say that
I'm still not knowledgeable in the property-resolving area that I can
cast a vote here. But it sounds good, nothing that disturbs me. I hope
that the people with intimate knowledge in this area all participate and
bring up any
Note: I added a page to the wiki for this thread.
http://nagoya.apache.org/wiki/apachewiki.cgi?PropertiesRedesign
After thinking about the proposal, I'm not sure it solves anything.
There are two aspects to the redesign of Property handling in FOP.
* Interface means the external points
John Austin wrote:
After thinking about the proposal, I'm not sure it solves anything.
Perhaps not. If the purpose of building a house is to supply shelter, then
building a foundation would seem also not to solve anything. However, it is
kind of a necessary first step toward the ultimate goal.
Victor, I was mostly backing away from my earlier posting which was
off-target.
On Tue, 2003-11-25 at 13:26, Victor Mote wrote:
John Austin wrote:
After thinking about the proposal, I'm not sure it solves anything.
you might make to the implementation would require (I think) changes to
John Austin wrote:
In order to adapt Peter's ideas, I would need identify the current
Interface(s). Ideally a re-implementation of Property handling would be
invisible outside of those classes.
I think we have a one-time cost of changing the interface. IOW, I think any
changes that you make
--- Victor Mote [EMAIL PROTECTED] wrote:
Also, as Glen
has pointed out, there
is business logic that can be pulled out of these
code modules back into FO
Tree where they more properly belong, and where
duplication and confusion
can be minimized.
A few more ideas:
(1.) You may find that
Please correct me if I'm wrong, I'm just sort of restating your
proposal to make sure I understand it and how it fits in the app. What
you're suggesting here is not to abandon the PropertyList, but to
encapsulate it by replacing get(name) with getName(). Then we lose the
dependency on the
On Mon, 2003-11-24 at 19:47, Victor Mote wrote:
FOP Developers:
Proposal:
I propose that public get methods be used to retrieve FO Tree property
values, and that the data behind these values be made as private as
possible. The methods should be given a name based on the XSL-FO Standard.
--- Victor Mote [EMAIL PROTECTED] wrote:
Proposal:
I propose that public get methods be used to
retrieve FO Tree property
values, and that the data behind these values be
made as private as
possible. The methods should be given a name based
on the XSL-FO Standard.
For example, the
John Austin wrote:
Proposal:
I propose that public get methods be used to retrieve FO Tree property
values, and that the data behind these values be made as private as
possible. The methods should be given a name based on the
XSL-FO Standard.
For example, the max-width property should
Glen Mazza wrote:
Not always--a getBorderBeforeColor() for a table cell
will need to take into account what was declared for
any row, column, and possibly table-edge that the its
before edge shares.
The border conflict resolution algorithm is described in
the CSS2 spec, see
Glen Mazza wrote:
--- Victor Mote [EMAIL PROTECTED] wrote:
Proposal:
I propose that public get methods be used to
retrieve FO Tree property
values, and that the data behind these values be
made as private as
possible. The methods should be given a name based
on the XSL-FO Standard.
43 matches
Mail list logo
