Re: line layout commit (coments on Keiron's commit)
Hi Karen, Its seems that there are gotcha's no matter what direction we take. I will try to present the reasons behind the approach I am taking. I welcome your input and I will look at the code to see how your code works. It seems we need a set of tough cases that we need to be able to handle to be confident of the correct approach. So why flatten the inline layout managers? If we have an example like this: blockSome text basic-linka paragraph of textblockwith a block/blockand more text/basic-link and inline background=blueblue backgroundinline color=green green text blocka block/block more green/inline/inline/block The basic link produces/returns both inline areas and a block area, so it is not possible to say that the basic-link element or its layout manager would produce inline areas. So how should this be handled. If it is flattened things are easier. The layout manager can then keep range information like: starts link, ends link. Determining line breaks: blocktext on a hyphenated line with a colinline color=redour/inlineed word/block In this case the text layout manager cannot determine a break after col, only the line layout manager can work out a suitable break point or hyphenation. (I don't know what your code does but this is why I simply get areas from the text layout manager) 12. This is the idea of the range properties. I can see how putting everything in a single inline area could be useful as long as other things are easily transparent. I was thinking of getting this information from the inline layout managers so that the line layout manager can deal with it appropriately. 3. Ideally the layout process should start as soon as the first block is ended (no matter how deep it is). So something like, when starting a block level element the layout manager is added to the parent, when a block level element is ended then the layout process starts and adds the areas from that block etc. How this will happen in practice I haven't really thought about. If the iterator can do that then we should use it. On 2002.04.29 00:16 Karen Lease wrote: Hi Keiron, Here are a few comments on your new layoutmgr stuff (which is definitely more advanced than mine in most ways) : 1. I can't figure out how/where you manage space-start, space-end, border, padding, background etc (ie, any non-inherited properties) for non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said, you're flattening the inline LM, so in fact, you're just adding the FO children of the inline. I think that if these FO _must_ create real inline areas if they have any non-inherited properties. If they don't they are acting kind of like fo:wrapper, and in that case, I agree we don't need a separate layout manager, because no area needs to be created. For basic-link, I think it would also be easier if it created an inline area containing its child areas even if it doesn't have any non-ineritable layout type properites. We could hang the linking information on that area (or areas, if it split across lines). But if we make nested inline areas, then the space adjustment as written in the LineLayoutManager won't work correctly, because it won't see the nested spaces. 2. Lack of context information: I ended up adding a LayoutContext oject to pass information down to the LM(s) generating the areas. This is to handle things like space-specifiers which can accumulate from various tree levels, and also to indicate when a LM is generating a break (or an Area) which is first in its parent area. That can influence things like conditional space and borders and padding. What's a pain with that stuff is that it changes the IPD, so until we know where the area is going to be placed, we don't know exactly how big it will be. 3. I'd like to avoid having to generate all the child LM before starting to layout any given level. This would limit us to waiting for a whole fo:flow to be done (unless we special case at that level). I think we can find a way to pull on the layout managers and still keep the flexibility you gain with the addLayoutManager(List) approach. I think it could be done with some kind of Iterator. (OK, I'm on kind of an Iterator fling recently, but they _are_ really handy. :-) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
I agree. That's why I want to get through this stage so that it is possible to concentrate on smaller self contained parts. For now I think these are the parts: - come up with our best line layout manager process - create a block/pagination process - document possible difficult cases, this will help everyone see why things are done in a particular way and the first one should be handled like you said. Then we should be ready to break things down into smaller parts for development. On 2002.04.28 23:47 Karen Lease wrote: Arved, I think the ownership idea is a good one. Especially since we now have some new committers who are full of energy and we have a batch of new code in the redesign branch which people can (and should!) look at and respond to. I think we can start like this: a) review the code which Kerion and I have committed in the last couple of days. b) discuss it here on the list; if it would then seem useful to have a more instantaneous forum to work out issues, we can work on setting that up. c) parcel out work on the code to various owners. There's lot's to do, so no one should feel left out. d) Communicate on the list (I think it's better than using the Status file, more spontaneous) about what we intend to do in the next iteration (next couple of weeks say). We could use a specific tag line like [PLANNING UPDATE] or some such so these messages wouldn't get lost in the forest. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: line layout commit
I live in the US. Florida, to be exact. I'd like to be able to attend and be a part of chat meetings, but I realize that I'm small potatoes on this project, so my needs should be secondary. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 9:19 PM To: fop-dev Subject: Re: line layout commit K, K, A and other developers, Regular chat sessions would probably have been useful here, and I think that they might still be useful. Probably every interested party but me is in the time zone spanned by Keiron and Arved. Anyone in the US? It should be possible for you to arrange some times. I would love to eavesdrop, and I would try to attend. What times would suit the three of you? Do you think it would be useful? Peter Karen Lease wrote: Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your thinking aloud mail last night and my feeling was that apart from the flattening of inline LM idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. Arved Sandstrom wrote: Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved, I think the ownership idea is a good one. Especially since we now have some new committers who are full of energy and we have a batch of new code in the redesign branch which people can (and should!) look at and respond to. I think we can start like this: a) review the code which Kerion and I have committed in the last couple of days. b) discuss it here on the list; if it would then seem useful to have a more instantaneous forum to work out issues, we can work on setting that up. c) parcel out work on the code to various owners. There's lot's to do, so no one should feel left out. d) Communicate on the list (I think it's better than using the Status file, more spontaneous) about what we intend to do in the next iteration (next couple of weeks say). We could use a specific tag line like [PLANNING UPDATE] or some such so these messages wouldn't get lost in the forest. Regards, Karen Arved Sandstrom wrote: I have some thoughts and suggestions, some of which we might adopt with varying degrees of success. 1. I can see a place for structured (that is, planned) communication: conference calls, scheduled meetings on a system like Peter describes, use of something like MSN Messenger, setting up an IRC channel and everyone getting together there. But I don't think that's the problem at the moment. 2. Can we do better with CVS? Maybe...reserved checkouts is overkill but perhaps watch features are indicated. We currently get commit notifications (I suspect through loginfo, probably, rather than a watch feature), but we don't know when someone started work on a file. If we used watches, we could set things up so Karen might get notifications on 'cvs edit' for such-and-such a package, Peter might get 'cvs edit' notifications on another package that he selects, and so forth, whatever is of interest. This would at least give us notifications at the other end of the process, which is when a developer (say, Keiron) _starts_ to work on a file. This is a bandaid, though. I am just as bad as Karen when it comes to wanting to have everything just-so before I check something in. This is OK with reserved checkout systems like SourceSafe default, but it's lousy for the unreserved checkout CVS case. I would nevertheless suggest maybe trying the watch features. I would otherwise really stress the use of a single-point-of-reference file, like STATUS, but I have my doubts about that. It has not proved out so far. What would be really sweet is if we had a visual aid that supplemented cvs watch features, maybe a page on the website that you could access that would indicate that a certain developer has run 'cvs edit' on file A, for example. Maybe ViewCVS does this already, I don't know. What we lack is ownership. We've got a whack of committers and a fair-few active ones, and maybe it's now time to allocate ownership of stuff on both branches. Ownership does _not_ mean you are the only person working in that package or packages - what it means is you are the POC for work being done in that package. You are the arbiter of disputes. We could even combine this with BugZilla ownership, possibly. Comments? If folks are agreed or at least not against it I can set up what needs to be setup. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 27, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: Re: line layout commit [ SNIP ] At any rate, I'm certainly not averse to having some more structured kind of communication about where to go from here be that a chat or just some discussion on the list of where we are and where we should go. As I mentioned, I'm going to dive in to his new stuff and study it carefully today and tomorrow; I'll probably have some questions and remarks at that point. [ SNIP ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (part 2)
Hi Foppers, I've gone ahead and committed the major part of the Break Possibility approach to layout managers which I have developped. It leaves Keiron's new code intact (except for a couple of changes I needed to make to be able to subclass his LineLayoutManager). It's also not activated; to do so there are two changes to make: org.apache.fop.fo.FOText: create a TextBPLayoutManager instead of a TextLayoutManager org.apache.fop.layoutmgr.BlockLayoutManager: create a LineBPLayoutManager instead of a LineLayoutManager Both changes are in comments. This code will run for blocks containing text but not much else. It's mostly just to illustrate the idea. I didn't try to work in the block-level versions of the BP layout managers, at least not for now. In most ways, it's a good deal less functional than Keiron's code; however it does have some code to handle resolution of sequences of space specifiers, and the text layout code has the start of some word-space handling. It might be helpful to have another look at the design document describing the general idea when looking at the code. Regards, Karen Keiron Liddle wrote: Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. [SNIP] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit (coments on Keiron's commit)
Hi Keiron, Here are a few comments on your new layoutmgr stuff (which is definitely more advanced than mine in most ways) : 1. I can't figure out how/where you manage space-start, space-end, border, padding, background etc (ie, any non-inherited properties) for non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said, you're flattening the inline LM, so in fact, you're just adding the FO children of the inline. I think that if these FO _must_ create real inline areas if they have any non-inherited properties. If they don't they are acting kind of like fo:wrapper, and in that case, I agree we don't need a separate layout manager, because no area needs to be created. For basic-link, I think it would also be easier if it created an inline area containing its child areas even if it doesn't have any non-ineritable layout type properites. We could hang the linking information on that area (or areas, if it split across lines). But if we make nested inline areas, then the space adjustment as written in the LineLayoutManager won't work correctly, because it won't see the nested spaces. 2. Lack of context information: I ended up adding a LayoutContext oject to pass information down to the LM(s) generating the areas. This is to handle things like space-specifiers which can accumulate from various tree levels, and also to indicate when a LM is generating a break (or an Area) which is first in its parent area. That can influence things like conditional space and borders and padding. What's a pain with that stuff is that it changes the IPD, so until we know where the area is going to be placed, we don't know exactly how big it will be. 3. I'd like to avoid having to generate all the child LM before starting to layout any given level. This would limit us to waiting for a whole fo:flow to be done (unless we special case at that level). I think we can find a way to pull on the layout managers and still keep the flexibility you gain with the addLayoutManager(List) approach. I think it could be done with some kind of Iterator. (OK, I'm on kind of an Iterator fling recently, but they _are_ really handy. :-) Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved Sandstrom wrote: What we lack is ownership. We could even combine this with BugZilla ownership, possibly. Creating an assigned bugzilla entry (ENH) works for other projects. I still think it's not quite sufficient for broad-scoped changes like the current redesign, but it might work well in the future when core changes will become more incremental again. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Arved, See comments below. Arved Sandstrom wrote: 1. I can see a place for structured (that is, planned) communication: conference calls, scheduled meetings on a system like Peter describes, use of something like MSN Messenger, setting up an IRC channel and everyone getting together there. But I don't think that's the problem at the moment. The problem is going to be with the timing. Scheduling a regulat chat would be a good idea because folks can try to schedule around that and, who knows, it could get to be a habit. 2. Can we do better with CVS? ,,, If we used watches, we could set things up so Karen might get notifications on 'cvs edit' for such-and-such a package, Peter might get 'cvs edit' notifications on another package that he selects, and so forth, whatever is of interest. This would at least give us notifications at the other end of the process, which is when a developer (say, Keiron) _starts_ to work on a file. This is a bandaid, though. I am just as bad as Karen when it comes to wanting to have everything just-so before I check something in. This is OK with reserved checkout systems like SourceSafe default, but it's lousy for the unreserved checkout CVS case. Yes and no. I think that the motivation for the CVS model was dissatisfaction with the RCS/SCCS lock model in precisely these situations; multiple developers, with some in the process of lengthy modifcations. I'm with you and Karen on this. My flesh creeps at the idea of committing code which I know to be in a shambolic state. It's worse if I have to then merge in someone else's changes, then iterate over the whole process a couple of days later. The situation is worse at the moment because basic design issues are being worked out on the fly, so there are going to be large, incompatible areas of the code between Karen and Keiron until the design is settled. My design is even more incompatible, so when I check my code in, I will be setting up my own branch. It seems to me that Karen might productively branch her changes, and track what Keiron is doing by merging in from his code. Take the current issue with her subclassing of Keiron's code. She need not have the code commented out in her branch, and she can explore the issues in safety. When she has proven the concept, she can merge back into the trunk. I don't think she is going to be left behind, but if she cannot develop her ideas in relative isolation from other ongoing and incompatible changes, a lot of her time may be spent in tedious merging activity. I would nevertheless suggest maybe trying the watch features. Agreed What we lack is ownership. We've got a whack of committers and a fair-few active ones, and maybe it's now time to allocate ownership of stuff on both branches. Ownership does _not_ mean you are the only person working in that package or packages - what it means is you are the POC for work being done in that package. You are the arbiter of disputes. We could even combine this with BugZilla ownership, possibly. The only trouble I see with this is that the only ones who are really familiar with the code are also *very* busy with development, part-time. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: line layout commit
I have some thoughts and suggestions, some of which we might adopt with varying degrees of success. 1. I can see a place for structured (that is, planned) communication: conference calls, scheduled meetings on a system like Peter describes, use of something like MSN Messenger, setting up an IRC channel and everyone getting together there. But I don't think that's the problem at the moment. 2. Can we do better with CVS? Maybe...reserved checkouts is overkill but perhaps watch features are indicated. We currently get commit notifications (I suspect through loginfo, probably, rather than a watch feature), but we don't know when someone started work on a file. If we used watches, we could set things up so Karen might get notifications on 'cvs edit' for such-and-such a package, Peter might get 'cvs edit' notifications on another package that he selects, and so forth, whatever is of interest. This would at least give us notifications at the other end of the process, which is when a developer (say, Keiron) _starts_ to work on a file. This is a bandaid, though. I am just as bad as Karen when it comes to wanting to have everything just-so before I check something in. This is OK with reserved checkout systems like SourceSafe default, but it's lousy for the unreserved checkout CVS case. I would nevertheless suggest maybe trying the watch features. I would otherwise really stress the use of a single-point-of-reference file, like STATUS, but I have my doubts about that. It has not proved out so far. What would be really sweet is if we had a visual aid that supplemented cvs watch features, maybe a page on the website that you could access that would indicate that a certain developer has run 'cvs edit' on file A, for example. Maybe ViewCVS does this already, I don't know. What we lack is ownership. We've got a whack of committers and a fair-few active ones, and maybe it's now time to allocate ownership of stuff on both branches. Ownership does _not_ mean you are the only person working in that package or packages - what it means is you are the POC for work being done in that package. You are the arbiter of disputes. We could even combine this with BugZilla ownership, possibly. Comments? If folks are agreed or at least not against it I can set up what needs to be setup. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Karen Lease Sent: April 27, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: Re: line layout commit [ SNIP ] At any rate, I'm certainly not averse to having some more structured kind of communication about where to go from here be that a chat or just some discussion on the list of where we are and where we should go. As I mentioned, I'm going to dive in to his new stuff and study it carefully today and tomorrow; I'll probably have some questions and remarks at that point. [ SNIP ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: line layout commit
Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have you looked at the Java reference implementation for it? :-) Not a trivial thing. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: line layout commit Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your thinking aloud mail last night and my feeling was that apart from the flattening of inline LM idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. I had done a bunch of work in Text and Line LM, but mostly it was totally new code, so after the CVS update your new stuff and mine are more or less coexisting. But I'll have another look at this tomorrow when I'm less tired to understand the details of your new stuff and to see if there's any useful way to integrate mine into it. It looks like you didn't change TextLayoutManager that much, so maybe some of my changes there could be worked in. The big difference is that I'm first generating a bunch of BreakPoss on the inline level which the LineLayoutManager is using to choose a break. In theory, it could do this for several lines at a time, but right now, it's just trying to do one. The the LineLM is also generating BreakPoss which represent the LineAreas it would create. Those eventually get bubbled up to the FlowLayoutManager which does basically the same thing as the LineLM. When it's happy, it uses the BreakPoss objects to have all the lower level LM generate the actual areas. I'll also have to adapt to the switch between getLayoutManager and addLayoutMangers though. I remember you mentioning this a while back, but I had continued to work along the original path. Don't think that will be too hard to do though. What I liked about the original approach is the idea that we could be laying out the tree in one thread and building it in another. But maybe that's still possible, just on a different level of chunking. At any rate, I'll try to see if I can add anything useful to your work. Do you think it's worthwhile trying to integrate the BreakPoss stuff or to commit it in some form so it would be public? -Karen Arved Sandstrom wrote: Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) As far as the Unicode bidi algorithm is concerned, yup, no kidding. :-) Have you looked at the Java reference implementation for it? :-) Not a trivial thing. Arved -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: April 26, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: line layout commit Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. If you run it over alignment.fo or instream.fo you will see that it mostly works for these examples. It does the spacing and vertical alignment. The main things that need thinking about are: - range properties - wrapping (ie. no wrap) - whitespace and linefeed handling - Unicode BIDI (this looks hard) It is very rough at the moment, the idea is to get a basis so that inline areas can be created and put into line areas and this will fit into the overall design. This leaves us with a simpler way of handing inline areas. So whats next? It is possible to start looking at fully implementing inline areas, eg. image, instream-foreign-object, leader, character. Getting pagination working will be a big step forward. Then we need to block area layout managers, like tables and lists. So what do people think? Regards, Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: line layout commit
K, K, A and other developers, Regular chat sessions would probably have been useful here, and I think that they might still be useful. Probably every interested party but me is in the time zone spanned by Keiron and Arved. Anyone in the US? It should be possible for you to arrange some times. I would love to eavesdrop, and I would try to attend. What times would suit the three of you? Do you think it would be useful? Peter Karen Lease wrote: Hi Keiron, On the one hand, I'm happy to see new work in the LayoutManagers. On the other hand, it turns out, I have been plugging (unfortunately really slowly) away at the Break Possibility ideas I mentioned a while back and just this very evening I had gotten the Line and Text LayoutManagers to where they were actually generating areas based on the BreakPoss ... and maybe it was ready for CVS. ... really I'm not kidding. That was when I discovered that you had beat me to it by a few hours. I only saw your thinking aloud mail last night and my feeling was that apart from the flattening of inline LM idea, there might not be such a big difference in our approaches. But of course, the code itself is quite different. Arved Sandstrom wrote: Very cool. I will try to pry away from my other project and also doing my income taxes and put in some quality time checking this out this weekend. Sounds like we are basically at the point where a bunch of us can usefully pitch in. :-) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Hi Developers, I just committed a bunch of changes to the line layout. I think it now has a reasonable basis to further develop the inline level areas and build line areas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
