Sorry, Vincent, I got busy with my packing up. Now, I have to reuse Chris' answer because I don't have your original post on my notebook.
On 22.06.2006 17:46:53 Chris Bowditch wrote: > Vincent Hennebert wrote: > > > Hi all, > > > > I'd like to have the opinion from the team about how I should proceed. > > I'm currently at a point where I think I know enough, both from > > theoretical and code points of vue, to start the implementation of > > floats. By mimicing the handling of footnotes, I think I can have a > > working implementation rather quickly and easily. However, it wouldn't > > be very satisfying IMO. Some refactoring wouldn't be useless, and while > > I'm at it, why not doing it completely? > > Sounds reasonable so far. As Simon said, don't get lost refactoring. Some amount of refactoring is certainly good (like extracting the footnote code into a separate class...) but your goal is before-floats. > > > > I've already spent much time figuring out how the code is working. From > > what I've seen, some areas of the code still look experimental. I think > > the implementation of floats may be an opportunity to bring it to a more > > "polished" level. A refactoring would have several benefits: > > - this may help sorting things out, and even prepare the implementation > > of a first-fit algorithm (although this might be a bit too much > > unrelated, I'm afraid) > > Jeremias mentioned the idea of different XSL-FO features requiring > different implementations of the Knuth algorithm, specifically first-fit > and total-fit. I get the impression though that they are usually > mutually exclusive and we cannot have one bit of the code using first > fit and another using total-fit. I'm not 100% sure that two implementations is really necessary. Maybe it's possible to scale down the total-fit to accomodate the first/best fit style tasks. But there will obviously be a negative inpact on before-float placement when things like changing available IPD on different pages comes up. I think I'd try to stick with the existing algorithm and we'll see about the changing IPD stuff from a different angle. Not a big chance for me this week to allocate much brain power to that task with all the things going on here. If it's possible to avoid introducing a separate breaking algorithm, I think we should do it. But at this point I'm not sure if it possible or not. > > - this may help future contributors to easier understand this area of > > the code and get involved more quickly > > Always a good thing. +1 > > - this is always better to have a clean design. Moreover, I think this > > is possible to make the implementation even more object-oriented, > > which would help sharing code between the line and page levels. > > This has always been a concern of mine. Although as I understand it > there are some differences between the two. > > > - a refactoring process is more efficient and secure if one has the > > opportunity to think full-time about it... > > I quite agree. If only I was a student again :) > > > > > That's why I would propose to refactor the breaking algorithm. However, > > to do things properly I would need to understand a bit more of the code > > than just the breaking stuff. This may take some time, especially if I > > want to make sure that I don't introduce new errors. The implementation > > of side-floats may suffer from that. That was not the original intent of > > the SoC project, but I think this would be a benefit for Fop. > > > > WDYT? Please do try to refactor the footnote and before-float stuff out into a separate class to make the whole design clearer. But don't shift your focus too much. Some factoring: +1, total refactoring -0.5, keep focus on your task: +1. ;-) <snip/> Jeremias Maerki
