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 <kl...@club-internet.fr> on 2001/09/03 23:22:31 UTC
Re: Layout Redesign
Hi Keiron,
I have read your design document carefully several times. The layout
manager idea has a familiar ring to it... something I had thought a
bunch about but never formalized as you have done. In essence, it sounds
like it would handle a bunch of stuff that the FO classes themselves are
currently trying to do. I was hesitating about moving more logic into
the areas themselves, but I think your idea of having a "middle
man(ager)" is better.
One attractive idea is that we could start with a fairly basic manager
as you describe, but could perhaps develop more sophisticated ones in
the long term (ie, manager is strategy). Also it's clear that the
manager which is doing line breaking (the Inline Manager?) will exist in
different versions to handle different kinds of writing-modes and styles
(western, CJK...)
I was trying to find a time when I was feeling more coherent to put my
questions and remarks together, but given all the traveling I'm doing
for work that's not happening. So I'll just start here by writing down a
few things that came to mind. Then if I've misunderstood what you meant,
we'll find out sooner.
I think my main concern is to be sure I understand where you are
actually thinking of doing the line building, ie. where the
inline-progression-dimension (IPD for short) of the columns will
actually be determined. Obviously this depends on the selection of the
page master to be used to hold the areas. That's a big part of what
motivated my bottom-up approach.
If the block layout managers (BLM) are actually created before the page
is made, then they can't make lines yet. That is one of the ideas I had
been playing with. In that case the manager is managing one or more
"inline flow sets" which is what I had called a sequence of characters
and other inline content which wasn't yet broken into lines. The BLM
might also manage nested BLM. When the parent manager asks the BLM to
produce an area, it sets the IPD and so the inline flow set can be
broken into lines. In general, all the layout managers need to know the
IPD in order to work. For examples non-fixed table layout depends on it,
leaders, and other expandable content like images which are scaled to
available space. For me this is a key issue.
Also you talk about how floating objects would be removed from the page
while looking for the best break, but you don't talk much about how they
get put on. Are you thinking they will be added at the moment where the
anchor is encountered? They at least have to be queued at that point or
signaled to the page-level LM. You mention that the BLM manages the
anchors. I was thinking of delegating to the LineArea objects
themselves; but obviously the key idea is that something knows about
them since the areas attached to them can move around during page
breaking.
Just a language issue: you talk of page balancing which makes me think
of balancing a multi-column page above a span or at the end of a flow;
but you seem to be using it to mean optimizing the break and
distributing the resulting vertical space. The term "VJ" for "vertical
justification" is often used for that process.
I like the user-agent idea a lot; it seems like an elegant way to handle
a lot of configuration issues. I remember worrying about that sometime
last year when I started to look at property values like "thin",
"thick", "smaller", etc.
I'm looking forward to continuing the discussion here.
Regards,
Karen
Keiron Liddle wrote:
>
> Hi All,
>
> I have written a document describing a possible way that we could implement
> the layout process (also has some info about user agent).
>
> I am hoping for feedback (particularly from those who have looked at the
> layout - Arved, Karen, Peter and others).
>
> It is mostly a description so there still may be some gotchas that I
> haven't considered. Hopefully this can provide some impetus to moving
> forward with the layout design so we can handle all these requests for
> things like keeps, spacing, line breaking (chinese characters), floats,
> large images, infinite loops etc. For those new to this area handlng a lot
> of these things is difficult with the current layout process in fop, hence
> the need for a new approach.
> ...
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Layout Redesign
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 01:59 PM 9/6/01 +0200, Keiron Liddle wrote:
>On Tue, 04 Sep 2001 12:37:34 Arved Sandstrom wrote:
>> One thing I was going to suggest is, and since you mentioned pictures
>> anyway, is let's take this as a useful working high-level design
>> description, and convert it into a high-level design doc, complete with
>> static and dynamic diagrams (UML or whatever). Seems to me that with this
>> doc we are definitely at the stage where prose has maybe been taken about
>> as
>> far as it will go.
>
>I had a quick look at Argo and its starting to look good for importing code
>in the latest (development) version. (has some bugs.)
>
>I could put the new design docs in the docs/design directory and in future
>we could use something like Argo to generate UML diagrams (exports svg)
>that can be included in the docs. The advantage being that anyone can grab
>argo and use it.
>
>Then we should be able to give a serious look at the lower level details.
Along those lines I'd recommend going for the Poseidon for UML application
from Gentleware AG, the Community Edition
(http://www.gentleware.com/products/download.php3). I downloaded it a few
days ago. It is mentioned on the ArgoUML project page and is a polished
version...looks really good.
You gave us a good start document, Keiron...I've been following the further
discussions and it seems to me that we really ought to take this to diagrams
ASAP. I'm thinking, too, that this is the best way for long-time FOP
developers to capture their knowledge and get it out to a wider audience.
That's not to say that we stop coding. :-)
If you want to divvy out bits of design I'll be happy to take one chunk.
Looks like you're currently design lead.
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: Layout Redesign
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Tue, 04 Sep 2001 12:37:34 Arved Sandstrom wrote:
> One thing I was going to suggest is, and since you mentioned pictures
> anyway, is let's take this as a useful working high-level design
> description, and convert it into a high-level design doc, complete with
> static and dynamic diagrams (UML or whatever). Seems to me that with this
> doc we are definitely at the stage where prose has maybe been taken about
> as
> far as it will go.
I had a quick look at Argo and its starting to look good for importing code
in the latest (development) version. (has some bugs.)
I could put the new design docs in the docs/design directory and in future
we could use something like Argo to generate UML diagrams (exports svg)
that can be included in the docs. The advantage being that anyone can grab
argo and use it.
Then we should be able to give a serious look at the lower level details.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Layout Redesign
Posted by Alex McLintock <al...@yahoo.com>.
--- Arved Sandstrom <Ar...@chebucto.ns.ca> wrote:
> One thing I was going to suggest is, and since you mentioned pictures
> anyway, is let's take this as a useful working high-level design
> description, and convert it into a high-level design doc, complete with
> static and dynamic diagrams (UML or whatever). Seems to me that with this
> doc we are definitely at the stage where prose has maybe been taken about as
> far as it will go.
Seconded. Clearer design docs will help get new developers and keep developers
on course. It also makes the whole project look more "professional" and
takes the sting out of refactoring the whole program :-)
Alex
=====
Alex McLintock alex@OWAL.co.uk Open Source Consultancy in London
OpenWeb Analysts Ltd, http://www.OWAL.co.uk/
SF and Computing Book News and Reviews: http://news.diversebooks.com/
Get Your XML T-Shirt <t-shirt/> at http://www.inversity.co.uk/
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Layout Redesign
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 11:51 AM 9/4/01 +0200, Keiron Liddle wrote:
>I think that I haven't explained some things very well. I have all these
>concepts in my head but its a bit difficult to write it in a coherent way,
>I need more pictures. (Reading it several times sounds like a bad sign :)
I read the document through several times this weekend. Last night I was
agonizing trying to write up a response, but I couldn't really think of
anything to say. Because overall I think the doc is in good shape.
One thing I was going to suggest is, and since you mentioned pictures
anyway, is let's take this as a useful working high-level design
description, and convert it into a high-level design doc, complete with
static and dynamic diagrams (UML or whatever). Seems to me that with this
doc we are definitely at the stage where prose has maybe been taken about as
far as it will go.
>One area I am really vague about is columns on pages with spanning and the
>balancing (this time I mean multi column page) process.
Happy to help. :-) I'd prefer to inject my ideas on this when we do up
design diagrams.
I actually did have a bunch of comments and ideas, but I realized that they
were really low-level (detailed) design things, so that can wait.
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: fop.jar
Posted by Duncan Hull <du...@csw.co.uk>.
Arved Sandstrom wrote:
>Did you check inside the build/ directory?
>
Hi Arved, thanks for your reply. Found it!
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fop.jar
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 11:11 AM 9/5/01 +0100, Duncan Hull wrote:
>
>The latest fop distribution (020) in http://xml.apache.org/dist/fop/
>does not contain a fop.jar file (as with previous versions). I would
>like to use the latest version of FOP but don't want to build it myself
>
>Is there a reason why the fop.jar is not included in the distribution
>any more?
Hi, Duncan
Did you check inside the build/ directory? I deliberately moved the fop.jar
into that directory, even for the binary distribution, so that the JAR would
be in the same place as for builds from source.
Regards,
Arved Sandstrom
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
fop.jar
Posted by Duncan Hull <du...@csw.co.uk>.
The latest fop distribution (020) in http://xml.apache.org/dist/fop/
does not contain a fop.jar file (as with previous versions). I would
like to use the latest version of FOP but don't want to build it myself
Is there a reason why the fop.jar is not included in the distribution
any more?
Duncan Hull
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Layout Redesign
Posted by "Peter B. West" <pb...@powerup.com.au>.
Keiron,
I'm not very coherent about this either, because I haven't yet developed
a good feel for it, but I will put down some random low-level responses.
I have just seen your response to Karen, but have not had time to try
to digest that yet.
I think that at some level, the flows can be composed into a line-area
galley (to go back to Karen's original term.) That galley then provides
lines of a given Inline Progression Dimension on demand from a higher
level. There are three levels of dimensioning: the dimensions of inline
components, including idividual characters and higher level constructs
of any kind; the IPDimension of a complete line, and the Block
Progression Dimension of a complete line. If the inline items are
marshalled into a galley, the first level of dimensioning can be
determined and associated with the galley. When a IPD is determined and
fed back to the galley, the line break and any adjustments (hyphenation,
glyph coalescing) can be made, possibly in a way that simply refers back
to the galley stream. Once the IPD is determined, the BPD can be
calculated.
When an area is fed upwards into the layout manager from, say, the
galley, it should be accompanied by a list of possible BPDimension
requirements. At the simplest level there may be only one; at another
level the list may contain the equivalent of minimum, optimal and
maximum BPDimension to accommodate vertical distribution of lines. When
a line-area contains a footnote reference, it could be the returning
line area that specifies the space required by the associated footnote,
after asking the question of the footnote galley. The possibilities
then include 1) postpone the footnote, 2) a single line of the footnote,
3) the separator and a single line of the footnote, 4) all the lines of
the footnote, with or without separator.
While the layout manager still has to distribute the appropriate
line-areas, it has a single point of decision as to what will be laid
out in association with this next line-area, based solely on the
available space.
When the layout manager makes a decision it feeds that decision back to
the galley, which realizes one of the options provided by 1) feeding up
any allowed body text line, and 2) notifying the footnote galley of the
decision about footnotes. A variant of this would be on the first line
of a new page, where the line-area layout manager would be aware of any
footnotes which are pending from a previous page. In this case, the
minimum values for the space required would be the inline-areas required
to flush the pending footnotes.
From the above, you may see that my get feeling for the way the layout
is handled is not one of laying out then trimming, but of offering
areas to the galleys/flow sets and seeing what possibilities come back,
then having the layout manager choose the set that works "best". There
may only be one member of this set, but in the case of footnotes there
can be more than one, and in the case of side floats there will most
likely be complications.
I want to read up on floats and think more about floats and multi-column
pages, but prima facie the approach above would work for multi-columns
with footnotes with little difference.
Peter
Karen Lease wrote:
> Hi Keiron,
>
> I have read your design document carefully several times. The layout
> manager idea has a familiar ring to it... something I had thought a
> bunch about but never formalized as you have done. In essence, it sounds
> like it would handle a bunch of stuff that the FO classes themselves are
> currently trying to do. I was hesitating about moving more logic into
> the areas themselves, but I think your idea of having a "middle
> man(ager)" is better.
>
> One attractive idea is that we could start with a fairly basic manager
> as you describe, but could perhaps develop more sophisticated ones in
> the long term (ie, manager is strategy). Also it's clear that the
> manager which is doing line breaking (the Inline Manager?) will exist in
> different versions to handle different kinds of writing-modes and styles
> (western, CJK...)
>
> I was trying to find a time when I was feeling more coherent to put my
> questions and remarks together, but given all the traveling I'm doing
> for work that's not happening. So I'll just start here by writing down a
> few things that came to mind. Then if I've misunderstood what you meant,
> we'll find out sooner.
>
> I think my main concern is to be sure I understand where you are
> actually thinking of doing the line building, ie. where the
> inline-progression-dimension (IPD for short) of the columns will
> actually be determined. Obviously this depends on the selection of the
> page master to be used to hold the areas. That's a big part of what
> motivated my bottom-up approach.
>
> If the block layout managers (BLM) are actually created before the page
> is made, then they can't make lines yet. That is one of the ideas I had
> been playing with. In that case the manager is managing one or more
> "inline flow sets" which is what I had called a sequence of characters
> and other inline content which wasn't yet broken into lines. The BLM
> might also manage nested BLM. When the parent manager asks the BLM to
> produce an area, it sets the IPD and so the inline flow set can be
> broken into lines. In general, all the layout managers need to know the
> IPD in order to work. For examples non-fixed table layout depends on it,
> leaders, and other expandable content like images which are scaled to
> available space. For me this is a key issue.
>
> Also you talk about how floating objects would be removed from the page
> while looking for the best break, but you don't talk much about how they
> get put on. Are you thinking they will be added at the moment where the
> anchor is encountered? They at least have to be queued at that point or
> signaled to the page-level LM. You mention that the BLM manages the
> anchors. I was thinking of delegating to the LineArea objects
> themselves; but obviously the key idea is that something knows about
> them since the areas attached to them can move around during page
> breaking.
>
> Just a language issue: you talk of page balancing which makes me think
> of balancing a multi-column page above a span or at the end of a flow;
> but you seem to be using it to mean optimizing the break and
> distributing the resulting vertical space. The term "VJ" for "vertical
> justification" is often used for that process.
>
> I like the user-agent idea a lot; it seems like an elegant way to handle
> a lot of configuration issues. I remember worrying about that sometime
> last year when I started to look at property values like "thin",
> "thick", "smaller", etc.
>
> I'm looking forward to continuing the discussion here.
>
> Regards,
> Karen
>
> Keiron Liddle wrote:
>
>>Hi All,
>>
>>I have written a document describing a possible way that we could
implement
>>the layout process (also has some info about user agent).
>>
>>I am hoping for feedback (particularly from those who have looked at the
>>layout - Arved, Karen, Peter and others).
>>
>>It is mostly a description so there still may be some gotchas that I
>>haven't considered. Hopefully this can provide some impetus to moving
>>forward with the layout design so we can handle all these requests for
>>things like keeps, spacing, line breaking (chinese characters), floats,
>>large images, infinite loops etc. For those new to this area handlng
a lot
>>of these things is difficult with the current layout process in fop,
hence
>>the need for a new approach.
>>...
>>
>
>
> ---------------------------------------------------------------------
> 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: Layout Redesign
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Karen,
I think that I haven't explained some things very well. I have all these
concepts in my head but its a bit difficult to write it in a coherent way,
I need more pictures. (Reading it several times sounds like a bad sign :)
Yes the IPD is a crucial part of the process.
The idea is to first let the page sequence object construct a page layout
manager, this page layout manager then grabs managers for all block areas
in the flow. At this stage the managers just have a reference to the
information no area creation is done.
Then the process of laying out a page is started. The page sequence creates
a page area object, then the block area layout managers are asked to add
their block area(s) into the current page (actually span area). So at this
stage the layout managers have the page in which the objects are being
placed. The idea is that a roughly valid page is created that can then be
vertically justified using the layout managers and information in the area
(sub)tree.
So when a block area is creating a line area it know exactly the width
available and adds inline areas until the line is full. Initially the areas
are added with minimum distance then once a line is full then it is
horizontally justified to find the optimum fit. I believe that no matter
how deep the block areas are stacked, with things like inline-container,
table etc. (side floats get the width from their children?) then the width
of the area is always known and can be supplied by the parent manager.
If a line area contains a float then it will place the float starting at
the current line, then when it comes to justifying the line the available
width is reduced by the width of the float. If the float, the inline float
anchor and the inline object it is kept with cannot fit on the line then
the line is cut short and the float stuff is placed on the next line.
For floats inside nested block areas I think it gets a bit more difficult.
What should happen for a float inside a table cell, when the table has a
percentage value for a table column width. I suppose the easiest solution
would be to place the side float in the next reference area.
The line area will know about the float (and footnotes) because of the
anchor inline area. The block also needs to know what line a float/footnote
is on. I'm trying to avoid getting into too much detail about where
information is kept. Hopefully it is enough to say that when a block area
is being split it may need to consider floats/footnotes inside some of the
lines in the block.
Although I am mostly talking about this from the top down I think the
actuall implementation will be about placing inline areas into lines, then
lines get placed into blocks then blocks into pages. I think that it is
easier to consider how to handle floats/footnotes etc from this angle.
One area I am really vague about is columns on pages with spanning and the
balancing (this time I mean multi column page) process.
Keiron.
On Mon, 03 Sep 2001 23:22:31 Karen Lease wrote:
> Hi Keiron,
>
> I have read your design document carefully several times. The layout
> manager idea has a familiar ring to it... something I had thought a
> bunch about but never formalized as you have done. In essence, it sounds
> like it would handle a bunch of stuff that the FO classes themselves are
> currently trying to do. I was hesitating about moving more logic into
> the areas themselves, but I think your idea of having a "middle
> man(ager)" is better.
>
> One attractive idea is that we could start with a fairly basic manager
> as you describe, but could perhaps develop more sophisticated ones in
> the long term (ie, manager is strategy). Also it's clear that the
> manager which is doing line breaking (the Inline Manager?) will exist in
> different versions to handle different kinds of writing-modes and styles
> (western, CJK...)
>
> I was trying to find a time when I was feeling more coherent to put my
> questions and remarks together, but given all the traveling I'm doing
> for work that's not happening. So I'll just start here by writing down a
> few things that came to mind. Then if I've misunderstood what you meant,
> we'll find out sooner.
>
> I think my main concern is to be sure I understand where you are
> actually thinking of doing the line building, ie. where the
> inline-progression-dimension (IPD for short) of the columns will
> actually be determined. Obviously this depends on the selection of the
> page master to be used to hold the areas. That's a big part of what
> motivated my bottom-up approach.
>
> If the block layout managers (BLM) are actually created before the page
> is made, then they can't make lines yet. That is one of the ideas I had
> been playing with. In that case the manager is managing one or more
> "inline flow sets" which is what I had called a sequence of characters
> and other inline content which wasn't yet broken into lines. The BLM
> might also manage nested BLM. When the parent manager asks the BLM to
> produce an area, it sets the IPD and so the inline flow set can be
> broken into lines. In general, all the layout managers need to know the
> IPD in order to work. For examples non-fixed table layout depends on it,
> leaders, and other expandable content like images which are scaled to
> available space. For me this is a key issue.
>
> Also you talk about how floating objects would be removed from the page
> while looking for the best break, but you don't talk much about how they
> get put on. Are you thinking they will be added at the moment where the
> anchor is encountered? They at least have to be queued at that point or
> signaled to the page-level LM. You mention that the BLM manages the
> anchors. I was thinking of delegating to the LineArea objects
> themselves; but obviously the key idea is that something knows about
> them since the areas attached to them can move around during page
> breaking.
>
> Just a language issue: you talk of page balancing which makes me think
> of balancing a multi-column page above a span or at the end of a flow;
> but you seem to be using it to mean optimizing the break and
> distributing the resulting vertical space. The term "VJ" for "vertical
> justification" is often used for that process.
>
> I like the user-agent idea a lot; it seems like an elegant way to handle
> a lot of configuration issues. I remember worrying about that sometime
> last year when I started to look at property values like "thin",
> "thick", "smaller", etc.
>
> I'm looking forward to continuing the discussion here.
>
> Regards,
> Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org