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]
