You are viewing a plain text version of this content. The canonical link for it is here.

Posted to fop-dev@xmlgraphics.apache.org by Karen Lease <ka...@club-internet.fr> on 2001/04/22 22:32:14 UTC

New architectural ideas

Hi fellow FOP'ers,

Along with Arved and others (thanks to Fabio Giannetti for his nice
drawings) I've been doing a lot of thinking about how to change the FOP
layout architecture to make it easier to resolve problems which can't be
handled locally. One idea that is common to all of these suggestions is
to break down the tree of flow objects into more easily manageable
chunks. I think mine is quite similar, though the basis for the chunking
is somewhat different.

My motivation is to stop trying to handle situations like keeps,
inter-object spacing and float positioning at the FO level. The code
there is too complicated (and often only handles part of the problem).
It seems like all this logic should be concentrated in one more global
class which knows how to "makeup the page". Going back to the galley
idea, I propose to make the layout() method simply generate areas and
put the correct traits on them, but not to try to worry about making
intelligent decisions about what areas should be kept together.

I'm going to try to the overall idea without being too long-winded.

Make layout more bottom up than top down. Instead of Flow first
generating an area, passing it to its child, which makes its area,
passees it to its child and so on down the tree, we would descend the
tree without passing the area. At the lowest level "atomic" nodes
(FOtext or some other atomic inline object, graphic for example), we
make an Area. To get the parent area, this FO asks its parent. At that
point, the parent either returns its current area if it isn't full (this
happens if a previous child already asked for one), or makes a new area
of the correct type. But it also needs a parent area. So this process
recurses up to the Flow level which will finally make a Column area of
the correct type. When an FO is requesting an Area, it has some flags.
One distinguishes between needing an area in which to put inlines or
blocks. Another lets it specify (for blocks) a column-width or spanning
area. Finally, it can also specify an area at the top of a column, page,
odd-page or even-page.

As Areas get filled they are added to their parent Area. This process
also is recursive. The result is that when an FO's current Area is full,
it will need to make a new one, which means "ending" its parent Area (no
Area can have more than one child Area which is generated by the same
FO). So new areas get made as we go along. In fact the layout process
never returns before all the children of the Flow are laid out. The Area
filling process doesn't worry about things like keeps. When the highest
level block is full, it just "ends" it and asks for a new one. It
assumes that someone else will worry about the details. However it must
set traits on the Area. This includes is-first, is-last, keeps
information and space-before/after information. (Note: I think that in
order to correctly calculate the "effective" space, it's easier to just
set these as traits on the generated areas rather than created "display
space" objects in the Area tree. Because of "conditional space" and
combinations of space generated by nested Areas, this can only be
calculated once the page is laid out completely.) 

This doesn't mean that we don't make any pages before the layout process
ends. I think we need two threads. One thread is running this layout
process, which is making "galleys". When a Flow object is asked to make
a new Area, it doesn't return a column-size area as now, but rather an
area that is big enough to hold a "page" of content. So if there are two
columns, and it is asked for a normal column-width area, it returns one
whose maximum block-progression-dimension is twice the height of the
region-body. The returned area doesn't yet really belong to a page but
rather to a "page-flow-set" or something like that. The page-flow-set
can have both spanning and non-spanning areas. There is also a way to
assocate floating objects (before-floats and footnotes) with the page
set. When a float-type FO is laid out, it asks for a float area. This
bubbles all the way up to the Flow object which returns an Area and
associates that Area with the current "normal" page-flow-set. While it's
doing this, it doesn't worry about whether the floats will actually fit
on the page with the anchor. That's the business of the second thread.

The second thread works on completed page-flow-set objects. It is
responsible for actually making break decisons, balancing columns,
placing floats and so on, based on all the areas in the page-flow-set
and the associated floats whose anchors are in the flow set. This logic
can be fairly simplistic or very complicated. But basically its input is
the page-flow-set and its output should be a completed Page, and a
flow-set containing the ares (normal and floating) it couldn't fit on
the page. For example, it may "throw" some areas because of keep, widow
or orphan conditions or because it placed a float and areas after the
float anchor no longer fit in the page. (NOTE: that the page makeup may
be obliged to violate certains conditions. That is why it needs the
global view and why we can't try to handle keeps locally.) The thrown
areas have priority to be placed on the following page. They  are merged
with the next page-flow-set before the page makeup manager gets a crack
at that (or maybe it gets both sets?)

A special case occurs when there are page-masters with different column
widths in a single page-sequence. In this case, we don't want the galley
layout thread to get too much ahead of the page makeup thread because it
won't layout stuff to the correct width. So there needs to be some
mechanism to "block" the gallye layout thread until the page-makeup
thread has caught up to it. Any areas which were "thrown" into this new
page master will need to be "reflowed" or maybe just completely
recomposed.

Areas need to implements some new operations. The most important one is
"split" which is  passed a desired split dimension (min-opt-max). It
must split the whole subtree to try to satisfy the desired dimension.
The split can have "costs" associated with it which are based on keep
values and similar constraints. This applies to inline as well as block
areas. For "text" areas, that's where hyphenation can come into play.

ALong with this, I also think we need to make Areas be more intelligent.
For example, when a child is added, the Area must know how that affects
its own size. FOs will not be responsible for telling areas to increase
their height. There will need to be some special case Areas for handling
ListItems and table FOs. Also, the "absolute" height calculation (if it
really needs to be done) will be done once the page makeup is finalized.

I think that's enough to give a general flavor. I've tried to "step
through" the galley-layout part and I feel fairly good about that. The
page-makeup is obviously harder, but I think the important thing is that
it has a bunch of material to work with and it can rearrange that using
whatever algorithm it wants in order to make a "good decision".

Best regards,
Karen Lease

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Jeremias Maerki <je...@outline.ch>.

> 5) there has been some discussion on Apache's general list to 
> switch from stylebook to docbook or something else. afaik there 
> has been a lot of voting for docbook but nobody has a working 
> solution to replace stylebook. We should monitor this discussion 
> and change as soon as possible.

Maybe have a look into the Avalon project. They have just started using
docbook.

Jeremias Märki

mailto:jeremias.maerki@outline.ch

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Inheritance for fo:marker

Posted by "Peter B. West" <pb...@powerup.com.au>.


Arved Sandstrom wrote:

 > At 01:46 AM 7/28/01 +1000, Peter B. West wrote:
 >
 >>Arved & Karen,
 >>
 >>On the surface of it, this re-parenting issue looks like a tree
 >>operation.  The point of definition of the marker remains in its context
 >>at the point of definition.  When a retrieve-marker is found, the marker
 >>sub-tree is attached as a child of the retrieve-marker.  As long as
 >>there is a check for cycles, there s no reason that a sub-tree cannot be
 >>attached at multiple points in the tree.  There are probably a few
 >>complications in terms of removal, but I have yet to work through all of
 >>these issues anyway.
 >>
 >
 > In fact, you're right, this would be much better. Rather than change the
 > parent of the original, just create a temporary copy that gets 
attached as a
 > child of the fo:retrieve-marker. Because the original should stay 
where it
 > is for future marker operations. In any case the code does not permit 
the
 > original to be laid-out, so there is no problem leaving the fo:marker 
there.


It shouldn't even have to be a temporary copy.  Because "[t]he 
fo:retrieve-marker does not directly generate any area. It is 
(conceptually) replaced by the children of the fo:marker that it 
retrieves" and because fo:retrieve-marker may have no other children, 
the appropriate fo:marker subtree can be added as a child of 
fo:retrieve-marker and left there.  Formatting of fo:retrieve-marker 
could then proceed as for any other subtree.  Well, it sounds good in 
theory.

Peter

-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Validation

Posted by "Peter B. West" <pb...@powerup.com.au>.

I noticed some comments on validation a few days ago.  To DTD or not to 
DTD and the like, including Karen's comment that she wanted to move a 
lot of the "semantic" validation into addChild.


I had been wondering why we weren't using a DTD to provide the first 
level of syntatic validation in the parser.  When I was thinking about 
the streaming of large documents, I felt that streaming tends to promote 
the parsing to the top of the processing hierachy.  I made some comments 
along these lines a few days ago.

It seems to me that, if the syntactic validation is to come into the 
code, it makes some sense to use the structure that is imposed by the 
syntactic structure of the XML to in turn structure not just the 
parsing, but, as much as possible, the processing.  I found, and this 
may be the newcomer effect, that in order to find my way around in the 
code, I needed to read the spec.  That told me what to look for next.  I 
would, rather, like to be able to read the code instead of reading the 
spec.  I exaggerate, but do you see my point?

Looking back over this, I see that it is largely a rehash of what I said 
before, so I'll leave it at that.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Inheritance for fo:marker

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.

At 01:46 AM 7/28/01 +1000, Peter B. West wrote:
>Arved & Karen,
>
>On the surface of it, this re-parenting issue looks like a tree 
>operation.  The point of definition of the marker remains in its context 
>at the point of definition.  When a retrieve-marker is found, the marker 
>sub-tree is attached as a child of the retrieve-marker.  As long as 
>there is a check for cycles, there s no reason that a sub-tree cannot be 
>attached at multiple points in the tree.  There are probably a few 
>complications in terms of removal, but I have yet to work through all of 
>these issues anyway.

In fact, you're right, this would be much better. Rather than change the 
parent of the original, just create a temporary copy that gets attached as a 
child of the fo:retrieve-marker. Because the original should stay where it 
is for future marker operations. In any case the code does not permit the 
original to be laid-out, so there is no problem leaving the fo:marker there.

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Inheritance for fo:marker

Posted by "Peter B. West" <pb...@powerup.com.au>.

Arved & Karen,

On the surface of it, this re-parenting issue looks like a tree 
operation.  The point of definition of the marker remains in its context 
at the point of definition.  When a retrieve-marker is found, the marker 
sub-tree is attached as a child of the retrieve-marker.  As long as 
there is a check for cycles, there s no reason that a sub-tree cannot be 
attached at multiple points in the tree.  There are probably a few 
complications in terms of removal, but I have yet to work through all of 
these issues anyway.

Peter


Arved Sandstrom wrote:

> Hi, Karen
> 
> OK, if you're going on vacation please don't spend too much time on this. :-) 
> Apart from maybe during travel. I can take a look at what is going on too, 
> based on your pointers so far. You make it sound fairly simple.
> 
> Regards,
> Arved
> 
> On Wednesday 25 July 2001 21:18, Karen Lease wrote:
> 
>>Hi again Arved,
>>
>>What may make this fairly easy is the fact that the PropertyList object
>>has its own parent reference, to its parent PropertyList. This is set in
>>the constructor for the PropertyList. Except when changing namespaces,
>>it's set to the property list of the FO parent object. Property
>>retrieval is dynamic and will climb the inheritance tree based on the
>>parentProperty value. Unlike the FO tree, the parent PropertyList
>>doesn't reference its children; there are only upwards pointers. So I
>>think if we just add a method to "reparent" the property list that might
>>do the trick.
>>
>>Things to watch out for:
>>use of methods like "from-parent()" in the property values, since these
>>are currently interpreted during PropertyList construction and not
>>during layout. Of course we might just say it's common sense not to use
>>those... at least for now.
>>
>>The other thing we'd have to do is flush the PropertyManager cache for
>>things like font-state. The PropertyList itself (or rather the Property
>>objects it holds) don't generally cache the results of requests (for
>>example, storing an inherited value directly), but the PropertyManager
>>does. Also the use of percentage values in properties causes them to be
>>interpreted during layout, and those "resolved" values are then stored
>>in the actual Property objects.
>>
>>That's about where I'm at right now. I'm going on vacation so I probably
>>won't be as active for the next few weeks, though I will probably
>>continue to mull over various things. On the other hand, tomorrow I have
>>a lot of travel time, so maybe I'll be able to poke at this Property
>>stuff and give you actual code instead of just advice!
>>
>>Best regards,
>>Karen
>>
>>Arved Sandstrom wrote:
>>
>>>If you run some examples, you'll see that where
>>>fo:marker/fo:retrieve-marker currently is incorrect is that the
>>>properties on fo:marker are inherited from the original parent, not from
>>>the parent in the fo:static-content once the marker has been retrieved.
>>>In effect, markers are re-useable (I already have to reset them before
>>>each layout), and they have to be able to dynamically re-parent, sort of
>>>having a static parent for the purposes of retrieval, and a dynamic or
>>>_effective_ parent for the purposes of layout.
>>>
>>>It is easy enough to figure out what the effective parent for layout is;
>>>my question is, since you are the properties guru, what is the most
>>>effective mechanism for re-initiating inheritance using this effective
>>>parent? This would have to be done every time a marker is used. I could
>>>work it out eventually, but I'm lazy. :-)
>>>
>>>Thanks. Arved.
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>>For additional commands, email: fop-dev-help@xml.apache.org
>>
> 


-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Inheritance for fo:marker

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.

Hi, Karen

OK, if you're going on vacation please don't spend too much time on this. :-) 
Apart from maybe during travel. I can take a look at what is going on too, 
based on your pointers so far. You make it sound fairly simple.

Regards,
Arved

On Wednesday 25 July 2001 21:18, Karen Lease wrote:
> Hi again Arved,
>
> What may make this fairly easy is the fact that the PropertyList object
> has its own parent reference, to its parent PropertyList. This is set in
> the constructor for the PropertyList. Except when changing namespaces,
> it's set to the property list of the FO parent object. Property
> retrieval is dynamic and will climb the inheritance tree based on the
> parentProperty value. Unlike the FO tree, the parent PropertyList
> doesn't reference its children; there are only upwards pointers. So I
> think if we just add a method to "reparent" the property list that might
> do the trick.
>
> Things to watch out for:
> use of methods like "from-parent()" in the property values, since these
> are currently interpreted during PropertyList construction and not
> during layout. Of course we might just say it's common sense not to use
> those... at least for now.
>
> The other thing we'd have to do is flush the PropertyManager cache for
> things like font-state. The PropertyList itself (or rather the Property
> objects it holds) don't generally cache the results of requests (for
> example, storing an inherited value directly), but the PropertyManager
> does. Also the use of percentage values in properties causes them to be
> interpreted during layout, and those "resolved" values are then stored
> in the actual Property objects.
>
> That's about where I'm at right now. I'm going on vacation so I probably
> won't be as active for the next few weeks, though I will probably
> continue to mull over various things. On the other hand, tomorrow I have
> a lot of travel time, so maybe I'll be able to poke at this Property
> stuff and give you actual code instead of just advice!
>
> Best regards,
> Karen
>
> Arved Sandstrom wrote:
> > If you run some examples, you'll see that where
> > fo:marker/fo:retrieve-marker currently is incorrect is that the
> > properties on fo:marker are inherited from the original parent, not from
> > the parent in the fo:static-content once the marker has been retrieved.
> > In effect, markers are re-useable (I already have to reset them before
> > each layout), and they have to be able to dynamically re-parent, sort of
> > having a static parent for the purposes of retrieval, and a dynamic or
> > _effective_ parent for the purposes of layout.
> >
> > It is easy enough to figure out what the effective parent for layout is;
> > my question is, since you are the properties guru, what is the most
> > effective mechanism for re-initiating inheritance using this effective
> > parent? This would have to be done every time a marker is used. I could
> > work it out eventually, but I'm lazy. :-)
> >
> > Thanks. Arved.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

-- 
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Karen Lease <kl...@club-internet.fr>.

Hmm, interesting question. I'll try to get my head back into properties
and think about it within the next couple of days.

-Karen

Arved Sandstrom wrote:

> 
> Speaking of stuff to do, Karen, I've got a request/question. You may or may
> not have seen that I have a request for clarification pending on the
> www-xsl-fo list concerning various aspects of markers - this has mostly to do
> with dotting i's and crossing t's. In the meantime I have been proceeding
> with a common-sense interpretation.
> 
> As of right now, a lot of fo:marker/fo:retrieve-marker more or less works.
> Not every FO that is allowed to have markers implements them yet, but
> fo:block does. Most of "retrieve-boundary" and "retrieve-position" also
> works. Now I need to go into testing mode, as well as for other stuff I've
> added, and finetune, but that's another story.
> 
> If you run some examples, you'll see that where fo:marker/fo:retrieve-marker
> currently is incorrect is that the properties on fo:marker are inherited from
> the original parent, not from the parent in the fo:static-content once the
> marker has been retrieved. In effect, markers are re-useable (I already have
> to reset them before each layout), and they have to be able to dynamically
> re-parent, sort of having a static parent for the purposes of retrieval, and
> a dynamic or _effective_ parent for the purposes of layout.
> 
> It is easy enough to figure out what the effective parent for layout is; my
> question is, since you are the properties guru, what is the most effective
> mechanism for re-initiating inheritance using this effective parent? This
> would have to be done every time a marker is used. I could work it out
> eventually, but I'm lazy. :-)
> 
> Thanks. Arved.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Inheritance for fo:marker

Posted by Karen Lease <kl...@club-internet.fr>.

Hi again Arved,

What may make this fairly easy is the fact that the PropertyList object
has its own parent reference, to its parent PropertyList. This is set in
the constructor for the PropertyList. Except when changing namespaces,
it's set to the property list of the FO parent object. Property
retrieval is dynamic and will climb the inheritance tree based on the
parentProperty value. Unlike the FO tree, the parent PropertyList
doesn't reference its children; there are only upwards pointers. So I
think if we just add a method to "reparent" the property list that might
do the trick.

Things to watch out for:
use of methods like "from-parent()" in the property values, since these
are currently interpreted during PropertyList construction and not
during layout. Of course we might just say it's common sense not to use
those... at least for now.

The other thing we'd have to do is flush the PropertyManager cache for
things like font-state. The PropertyList itself (or rather the Property
objects it holds) don't generally cache the results of requests (for
example, storing an inherited value directly), but the PropertyManager
does. Also the use of percentage values in properties causes them to be
interpreted during layout, and those "resolved" values are then stored
in the actual Property objects.

That's about where I'm at right now. I'm going on vacation so I probably
won't be as active for the next few weeks, though I will probably
continue to mull over various things. On the other hand, tomorrow I have
a lot of travel time, so maybe I'll be able to poke at this Property
stuff and give you actual code instead of just advice!

Best regards,
Karen

Arved Sandstrom wrote:
> 
> If you run some examples, you'll see that where fo:marker/fo:retrieve-marker
> currently is incorrect is that the properties on fo:marker are inherited from
> the original parent, not from the parent in the fo:static-content once the
> marker has been retrieved. In effect, markers are re-useable (I already have
> to reset them before each layout), and they have to be able to dynamically
> re-parent, sort of having a static parent for the purposes of retrieval, and
> a dynamic or _effective_ parent for the purposes of layout.
> 
> It is easy enough to figure out what the effective parent for layout is; my
> question is, since you are the properties guru, what is the most effective
> mechanism for re-initiating inheritance using this effective parent? This
> would have to be done every time a marker is used. I could work it out
> eventually, but I'm lazy. :-)
> 
> Thanks. Arved.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.

On Sunday 22 July 2001 21:30, Karen Lease wrote:
> Welcome back Fotis!
> Oder soll ich sagen: Herr Doktor Jannidis? ;-)
>
> It looks like we need to update the "implemented" list too, at least
> when/before we do the next release, since lots of stuff has been
> happening lately.

We are on track for the monthly (first week of the month) release, I figure. 
So FOP 0.20.0 will be first week of August, immediately after Tore reformats, 
unless someone has objections.

> Redesign: personally, I haven't forgotten about it at all, but I've put
> it down temporarily while doing a bunch of table fixes and new
> functionality (spanning rows and vertical alignment - finally!) that
> seemed necessary to keep our user base working while the redesign goes
> on. I'm sure Keiron and Arved will have their words to put in, but it
> looks to me as though they've been working on a lot of "fundamentals" -
> adding properties and FOs - so that
> we can move closer towards compliance.

I am exactly in the same boat...couldn't ignore the fact that the existing 
FOP codebase needs lots of work. The redesign is all very good, but it is 
going to have to take second place as far as my time is concerned.

Speaking of stuff to do, Karen, I've got a request/question. You may or may 
not have seen that I have a request for clarification pending on the 
www-xsl-fo list concerning various aspects of markers - this has mostly to do 
with dotting i's and crossing t's. In the meantime I have been proceeding 
with a common-sense interpretation.

As of right now, a lot of fo:marker/fo:retrieve-marker more or less works. 
Not every FO that is allowed to have markers implements them yet, but 
fo:block does. Most of "retrieve-boundary" and "retrieve-position" also 
works. Now I need to go into testing mode, as well as for other stuff I've 
added, and finetune, but that's another story.

If you run some examples, you'll see that where fo:marker/fo:retrieve-marker 
currently is incorrect is that the properties on fo:marker are inherited from 
the original parent, not from the parent in the fo:static-content once the 
marker has been retrieved. In effect, markers are re-useable (I already have 
to reset them before each layout), and they have to be able to dynamically 
re-parent, sort of having a static parent for the purposes of retrieval, and 
a dynamic or _effective_ parent for the purposes of layout.

It is easy enough to figure out what the effective parent for layout is; my 
question is, since you are the properties guru, what is the most effective 
mechanism for re-initiating inheritance using this effective parent? This 
would have to be done every time a marker is used. I could work it out 
eventually, but I'm lazy. :-)

Thanks. Arved.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Karen Lease <kl...@club-internet.fr>.

Welcome back Fotis!
Oder soll ich sagen: Herr Doktor Jannidis? ;-)

It looks like we need to update the "implemented" list too, at least
when/before we do the next release, since lots of stuff has been
happening lately.

Redesign: personally, I haven't forgotten about it at all, but I've put
it down temporarily while doing a bunch of table fixes and new
functionality (spanning rows and vertical alignment - finally!) that
seemed necessary to keep our user base working while the redesign goes
on. I'm sure Keiron and Arved will have their words to put in, but it
looks to me as though they've been working on a lot of "fundamentals" -
adding properties and FOs - so that 
we can move closer towards compliance.

I think there is still agreement that FOP layout code will need major
revisiting in order to solve any kind of tough pagination problem
(floats, footnotes, keeps, correct inter-element spacing, full
implementation of "collapse" style table borders... among others). But
there is obviously also a need to keep supporting the current thread of
development which is letting lots of folks do their work, even without
all that fancy stuff.

Gruesse,
Karen

Fotis Jannidis wrote:
> 
> Hi,
> 
> I have finished my work and can put some time into Fop again. I
> will concentrate on updating the documentation (the status file
> indicates that nobody is working on this at the moment).
> 
> To do:
> 
> 1) update the history file
> 
> 2) update "running Fop" to include new switches etc.
> 
> 3) update the direction how to use cvs to use cvs.apache.org
> 
> 4) description of the new test suite
> 
> 5) there has been some discussion on Apache's general list to
> switch from stylebook to docbook or something else. afaik there
> has been a lot of voting for docbook but nobody has a working
> solution to replace stylebook. We should monitor this discussion
> and change as soon as possible.
> 
> Please point me to anything else which needs to be changed as
> soon as possible.
> 
> Some questions:
> 
> 1) What is the status of the redesign process?
> 
> 2) Do we have a fop-user list now?
> 
> 3) What is the status of the improvements of memory usage?
> 
> Fotis
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Christian Geisert <Ch...@isu-gmbh.de>.

Fotis Jannidis wrote:
> 
> Hi,
> 
> I have finished my work and can put some time into Fop again. I
> will concentrate on updating the documentation (the status file
> indicates that nobody is working on this at the moment).

Ja, du wirst hier dringend gebraucht ;-)

> To do:

[..]

> Please point me to anything else which needs to be changed as
> soon as possible.

- Code conventions
As Jeremias already mentioned some days ago, the code conventions should be
added to the website (under 'Getting involved' ?)

- JDK issue
There seems to be more or less consensus that FOP will require JDK1.2,
if this is the case it should be noted on the website.
Or should we first vote on this?

- News section
What about a section on the website which list important changes (with date)
like releases, significant code changes/additions or other important events
so that a user can see at a glance whats going on with FOP

> 
> Fotis

Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: back

Posted by Keiron Liddle <ke...@aftexsw.com>.

On Sun, 22 Jul 2001 12:45:51 Fotis Jannidis wrote:
> 4) description of the new test suite

There is some stuff there so far but more information (and from a different
perspective) is always welcome.

> Please point me to anything else which needs to be changed as 
> soon as possible.

There is the todo list that I posted a few days ago (and have added to
since) but it is not urgent. It also needs some comments about what it all
means.

> Some questions: 
> 
> 1) What is the status of the redesign process? 

>From my point of view you can look at it this way.
The redesign of the layout is required to properly handle how all elements
are layed out into the area tree.
This means two things:
- we need to be able to read all the elements properly (including
properties) to be able to properly use the information
- we need a proper area tree to put the areas into. ie. contains the right
logic and has viewports

So until we have these things we can't code the layout properly anyway.

> 2) Do we have a fop-user list now? 

yes.
The xml mailing list page also needs updating. At:
http://xml.apache.org/mail.html

> 3) What is the status of the improvements of memory usage?

I think the incorporation of memory improvements should be done once all
renderers are working with the changes (or time is allowed for it to
happen).

Welcome back.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

back

Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.

Hi, 

I have finished my work and can put some time into Fop again. I 
will concentrate on updating the documentation (the status file 
indicates that nobody is working on this at the moment). 

To do: 

1) update the history file

2) update "running Fop" to include new switches etc. 

3) update the direction how to use cvs to use cvs.apache.org

4) description of the new test suite

5) there has been some discussion on Apache's general list to 
switch from stylebook to docbook or something else. afaik there 
has been a lot of voting for docbook but nobody has a working 
solution to replace stylebook. We should monitor this discussion 
and change as soon as possible.

Please point me to anything else which needs to be changed as 
soon as possible.

Some questions: 

1) What is the status of the redesign process? 

2) Do we have a fop-user list now? 

3) What is the status of the improvements of memory usage?

Fotis



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Karen Lease <ka...@club-internet.fr>.

About "dia", I just discovered that while browsing through all the
software installed on my new system :-))) It has a UML dialect for
diagramming and it can save as SVG. I haven't yet tested whether the SVG
can be handled by FOP.... That would be nice!
-Karen

Arved Sandstrom wrote:
> 
> On Sunday 22 April 2001 22:53, Kelly Campbell wrote:
> > On Sun, Apr 22, 2001 at 11:36:58PM +0200, Karen Lease wrote:
> > > Boy, that was fast!
> > > The current design documents are a bunch of paper covered with boxes,
> > > arrows and scribbles. There are things that look like UML sequence
> > > diagrams in there; that's probably one of the best ways to see the
> > > layout stuff working. I'll try to get that into electronic form. Anyone
> > > have any alternatives to Rational Rose for that (especially if it runs
> > > under Linux!)
> > >
> > > -Karen
> >
> > I've been happy with ArgoUML (www.argouml.org).
> > Another tool I use for UML is dia (part of Gnome now I think). I use argo
> > for basic object diagrams, and dia for sequence diagrams.
> >
> > -Kelly
> 
> I second ArgoUML; in its latest stable incarnation (0.8.1) it does class,
> use-case, collaboration & deployment diagrams. OK, it's not as heavy-weight
> as TogetherJ (which I also use, courtesy of work), but it's reasonably fast,
> not that much of a hog, and has some neat features. I like what these guys
> are doing.
> 
> I'll check into "dia"; always on the lookout for neat new stuff. :-)
> 
> Regards,
> Arved
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Tore Engvig <te...@infostream.no>.


On Sun, 22 Apr 2001, Arved Sandstrom wrote:

> I second ArgoUML; in its latest stable incarnation (0.8.1) it does class, 
> use-case, collaboration & deployment diagrams. OK, it's not as heavy-weight 
> as TogetherJ (which I also use, courtesy of work), but it's reasonably fast, 
> not that much of a hog, and has some neat features. I like what these guys 
> are doing.

Besides, it can export diagrams in svg which is kind of fop friendly :)
I haven't seen other tools that export svg, only wmf or eps (non-vector
formats doesn't count!)


Tore

> 
> I'll check into "dia"; always on the lookout for neat new stuff. :-)
> 
> Regards,
> Arved
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.

On Sunday 22 April 2001 22:53, Kelly Campbell wrote:
> On Sun, Apr 22, 2001 at 11:36:58PM +0200, Karen Lease wrote:
> > Boy, that was fast!
> > The current design documents are a bunch of paper covered with boxes,
> > arrows and scribbles. There are things that look like UML sequence
> > diagrams in there; that's probably one of the best ways to see the
> > layout stuff working. I'll try to get that into electronic form. Anyone
> > have any alternatives to Rational Rose for that (especially if it runs
> > under Linux!)
> >
> > -Karen
>
> I've been happy with ArgoUML (www.argouml.org).
> Another tool I use for UML is dia (part of Gnome now I think). I use argo
> for basic object diagrams, and dia for sequence diagrams.
>
> -Kelly

I second ArgoUML; in its latest stable incarnation (0.8.1) it does class, 
use-case, collaboration & deployment diagrams. OK, it's not as heavy-weight 
as TogetherJ (which I also use, courtesy of work), but it's reasonably fast, 
not that much of a hog, and has some neat features. I like what these guys 
are doing.

I'll check into "dia"; always on the lookout for neat new stuff. :-)

Regards,
Arved

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Kelly Campbell <ca...@merlot.channelpoint.com>.

On Sun, Apr 22, 2001 at 11:36:58PM +0200, Karen Lease wrote:
> Boy, that was fast!
> The current design documents are a bunch of paper covered with boxes,
> arrows and scribbles. There are things that look like UML sequence
> diagrams in there; that's probably one of the best ways to see the
> layout stuff working. I'll try to get that into electronic form. Anyone
> have any alternatives to Rational Rose for that (especially if it runs
> under Linux!)
> 
> -Karen

I've been happy with ArgoUML (www.argouml.org).
Another tool I use for UML is dia (part of Gnome now I think). I use argo
for basic object diagrams, and dia for sequence diagrams.

-Kelly
-- 
Kelly A. Campbell              Software Engineer
<ca...@merlotxml.org>           ChannelPoint, Inc.
<ca...@channelpoint.com>        Colorado Springs, Co.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Petr Andrs <pa...@artax.karlin.mff.cuni.cz>.

There exists IDE (written in Java) which can generate UML class 
diagrams from java source and vice versa. It's name is Together and 
some version can be downloaded from http://www.togethersoft.com for 
free. It is bit memory consuming, it takes 100MB on launch. It can 
eport these diagrams into WMF and GIF.

pa

On 22 Apr 2001, at 23:36 Karen Lease wrote about Re: New architectural ideas :

> Boy, that was fast!
> The current design documents are a bunch of paper covered with boxes,
> arrows and scribbles. There are things that look like UML sequence
> diagrams in there; that's probably one of the best ways to see the
> layout stuff working. I'll try to get that into electronic form. Anyone
> have any alternatives to Rational Rose for that (especially if it runs
> under Linux!)
> 
> -Karen
> 
> 
> Arved_37@chebucto.ns.ca wrote:
> > 
> > Quoting Karen Lease <ka...@club-internet.fr>:
> > 
> > > Along with Arved and others (thanks to Fabio Giannetti for his nice
> > > drawings) I've been doing a lot of thinking about how to change the
> > > FOP layout architecture to make it easier to resolve problems which
> > > can't be handled locally. One idea that is common to all of these
> > > suggestions is to break down the tree of flow objects into more
> > > easily manageable chunks. I think mine is quite similar, though the
> > > basis for the chunking is somewhat different.
> > 
> > [ SNIP Actual ideas ]
> > 
> > Yes, I agree. The reason I agree is very simple - I was looking at how
> > the situation of a nested fo:block with span='all' can be handled now
> > (answer: with great difficulty), how the idea of clusters or wrappers
> > at the FO tree level would help this case (answer: not much, if at
> > all), and since the other obvious solution is (as Karen points out)
> > bottom-up, and this solution actually is exactly what I need to solve
> > this particular problem, I personally think it's the best way to go.
> > 
> > I'm satisfied (particularly after Karen's description) that we can
> > handle our layout problems with the bottom-up approach. I think there
> > may be circumstances where it makes sense to augment the FO tree
> > nevertheless, with wrapper FOs (whatever we call them), but the
> > reasons won't be layout, per se. That remains to be seen.
> > 
> > I guess the important thing now is, we need some design documents -
> > diagrams, pseudocode, whatever works. It's absolutely key to the
> > success of this that all the developers can understand the design, and
> > that the entry barrier to writing new code is sufficiently low. If we
> > can start with Karen's ideas, and convert them into a set of designs,
> > and everyone buys into it, we'll know if it's going to work, and we
> > won't be bogged down into code (although a branch for temporary
> > demo/design work might not be a bad idea). This is one of the moments
> > where I think we absolutely need a development lead, and Karen, I
> > suggest that you are it. :-)
> > 
> > Regards,
> > Arved
> > 
> > ---------------------------------------------------------------
> >  This mail was sent through the Nova Scotia Provincial Server,
> >  with technical resources provided by Chebucto Community Net.
> >  http://nsaccess.ns.ca/mail/         http://www.chebucto.ns.ca/
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org For
> > additional commands, email: fop-dev-help@xml.apache.org
> 
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org For additional
> commands, email: fop-dev-help@xml.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Karen Lease <ka...@club-internet.fr>.

Boy, that was fast!
The current design documents are a bunch of paper covered with boxes,
arrows and scribbles. There are things that look like UML sequence
diagrams in there; that's probably one of the best ways to see the
layout stuff working. I'll try to get that into electronic form. Anyone
have any alternatives to Rational Rose for that (especially if it runs
under Linux!)

-Karen


Arved_37@chebucto.ns.ca wrote:
> 
> Quoting Karen Lease <ka...@club-internet.fr>:
> 
> > Along with Arved and others (thanks to Fabio Giannetti for his nice
> > drawings) I've been doing a lot of thinking about how to change the FOP
> > layout architecture to make it easier to resolve problems which can't be
> > handled locally. One idea that is common to all of these suggestions is
> > to break down the tree of flow objects into more easily manageable
> > chunks. I think mine is quite similar, though the basis for the chunking
> > is somewhat different.
> 
> [ SNIP Actual ideas ]
> 
> Yes, I agree. The reason I agree is very simple - I was looking at how the
> situation of a nested fo:block with span='all' can be handled now (answer: with
> great difficulty), how the idea of clusters or wrappers at the FO tree level
> would help this case (answer: not much, if at all), and since the other obvious
> solution is (as Karen points out) bottom-up, and this solution actually is
> exactly what I need to solve this particular problem, I personally think it's
> the best way to go.
> 
> I'm satisfied (particularly after Karen's description) that we can handle our
> layout problems with the bottom-up approach. I think there may be circumstances
> where it makes sense to augment the FO tree nevertheless, with wrapper FOs
> (whatever we call them), but the reasons won't be layout, per se. That remains
> to be seen.
> 
> I guess the important thing now is, we need some design documents - diagrams,
> pseudocode, whatever works. It's absolutely key to the success of this that all
> the developers can understand the design, and that the entry barrier to writing
> new code is sufficiently low. If we can start with Karen's ideas, and convert
> them into a set of designs, and everyone buys into it, we'll know if it's going
> to work, and we won't be bogged down into code (although a branch for temporary
> demo/design work might not be a bad idea). This is one of the moments where I
> think we absolutely need a development lead, and Karen, I suggest that you are
> it. :-)
> 
> Regards,
> Arved
> 
> ---------------------------------------------------------------
>  This mail was sent through the Nova Scotia Provincial Server,
>  with technical resources provided by Chebucto Community Net.
>  http://nsaccess.ns.ca/mail/         http://www.chebucto.ns.ca/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: New architectural ideas

Posted by Ar...@chebucto.ns.ca.

Quoting Karen Lease <ka...@club-internet.fr>:

> Along with Arved and others (thanks to Fabio Giannetti for his nice
> drawings) I've been doing a lot of thinking about how to change the FOP
> layout architecture to make it easier to resolve problems which can't be
> handled locally. One idea that is common to all of these suggestions is
> to break down the tree of flow objects into more easily manageable
> chunks. I think mine is quite similar, though the basis for the chunking
> is somewhat different.

[ SNIP Actual ideas ]

Yes, I agree. The reason I agree is very simple - I was looking at how the
situation of a nested fo:block with span='all' can be handled now (answer: with
great difficulty), how the idea of clusters or wrappers at the FO tree level
would help this case (answer: not much, if at all), and since the other obvious
solution is (as Karen points out) bottom-up, and this solution actually is
exactly what I need to solve this particular problem, I personally think it's
the best way to go.

I'm satisfied (particularly after Karen's description) that we can handle our
layout problems with the bottom-up approach. I think there may be circumstances
where it makes sense to augment the FO tree nevertheless, with wrapper FOs
(whatever we call them), but the reasons won't be layout, per se. That remains
to be seen.

I guess the important thing now is, we need some design documents - diagrams,
pseudocode, whatever works. It's absolutely key to the success of this that all
the developers can understand the design, and that the entry barrier to writing
new code is sufficiently low. If we can start with Karen's ideas, and convert
them into a set of designs, and everyone buys into it, we'll know if it's going
to work, and we won't be bogged down into code (although a branch for temporary
demo/design work might not be a bad idea). This is one of the moments where I
think we absolutely need a development lead, and Karen, I suggest that you are
it. :-)

Regards,
Arved


---------------------------------------------------------------
 This mail was sent through the Nova Scotia Provincial Server, 
 with technical resources provided by Chebucto Community Net.
 http://nsaccess.ns.ca/mail/         http://www.chebucto.ns.ca/


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org