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
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
talkin
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 wit
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
co
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 it
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 t
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
--- 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-di
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 marker
John Austin wrote:
I am just thinking of ensuring that objects disappear after the
page they are on has been printed.
FOs can generate areas on multiple pages. You'll have to keep
a list of "terminated" FOs where the layout was finished (in
most cases this means the loop over the children run out).
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 s
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 issu
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 *wil
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.
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 th
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
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 {
> &g
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 abo
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 uses
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 stati
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
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). So
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
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 yo
--- 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 su
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 Layo
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
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 e
--- 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
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 f
--- "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 t
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 benef
--- 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 f
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, 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 t
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.
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 of
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 is
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 th
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
http://www.w3.org/TR/RE
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" pr
--- 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, t
Joe DeVivo wrote:
> 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
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 Stand
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 HashM
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 benefits to nailing down
46 matches
Mail list logo
