[GSoC] How the work should progress

[Vincent Hennebert <vi...@enseeiht.fr>]

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?

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)
- this may help future contributors to easier understand this area of
   the code and get involved more quickly
- 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.
- a refactoring process is more efficient and secure if one has the
   opportunity to think full-time about it...

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?
Vincent

Re: [GSoC] How the work should progress

[Vincent Hennebert <vi...@enseeiht.fr>]

Chris, Simon,

Thanks for your feedback. It seems that I've missed Jeremias before he
goes in Ireland. Too bad that my mail took half an hour to arrive.

Anyway, I have work to do on my thesis during a few days. Hopefully
Jeremias will be able to look at his mails during the conference. If
not, I'll follow Simon's advice and refactor just what is necessary to
implement floats.

Cheers,
Vincent


Simon Pepping a écrit :
> On Wed, Jun 21, 2006 at 04:32:29PM +0200, 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?
> 
> 
> Be careful. Don't let yourself be sidetracked by other worthy
> objectives. Stay focused on your target; it will be difficult enough.
>  
> 
>>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)
> 
> 
> I would hope that a best-fit algorithm can be inserted.
> 
> Regards, Simon
> 
> 

Re: [GSoC] How the work should progress

[Simon Pepping <sp...@leverkruid.eu>]

On Wed, Jun 21, 2006 at 04:32:29PM +0200, 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?

Be careful. Don't let yourself be sidetracked by other worthy
objectives. Stay focused on your target; it will be difficult enough.
 
> 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)

I would hope that a best-fit algorithm can be inserted.

Regards, Simon


-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: [GSoC] How the work should progress

[Vincent Hennebert <vi...@enseeiht.fr>]

Hi Jeremias,

<snip/>
> 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. ;-)

Ok. So definitely I'll just refactor what is necessary to cleanly
implement before-floats. That said, some further refactoring might be
needed for side-floats... But we'll see at that moment.

Thanks,
Vincent

Re: [GSoC] How the work should progress

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: [GSoC] How the work should progress

[Chris Bowditch <bo...@hotmail.com>]

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.

> 
> 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.

> - this may help future contributors to easier understand this area of
>   the code and get involved more quickly

Always a good thing.

> - 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?

I think you need Jeremias's input here before proceeding further. He's 
going to be offline for about 10 days I think.

Chris