Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

[Vincent Hennebert <vh...@gmail.com>]

2006/8/11, Apache Wiki:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
>
> The following page has been changed by VincentHennebert:
> http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats
>
> The comment on the change is:
> Difficulties around side-floats

Ok guys, I've been searching for 3 days for a simple, elegant, powerful,
effective, ligthweight solution to make the total-fit algorithm work
with side-floats, but can't seem to find one. This issue is somewhat
related to the one regarding differing available ipd in page sequences
(solving one might help solve the other one, at least). There is also
some similarity with tables, i.e., how to combine several "vertical"
Knuth element lists into just one. Excepted that in the case of
side-floats, we may choose several completely different solutions to
place them. And this is a case-by-case decision: one time this will be
better to differ the float, one other time to break it, one other time
to compress it...

In some situations, a best-fit approach could even produce better
results, as we would have the possibility to consider the differing of a
side-float. But it is well-known that best-fit may be much worse than
total-fit regarding before-floats and footnote placements.

Looking at how tables are handled might give me some ideas for
side-floats, but this would require some time and there isn't much left
now.

I also have some ideas for improving the handling of before-floats and
footnotes, and I'd like to implement them while I have time and it's
still fresh in my memory.

The implementation I propose on the Wiki page has its limitations but
should work in most cases. This might give a basis for further
improvements.

I'm thinking about making a poll on fop-user to know what are their
expectations regarding side-floats, and which usage they would make of
them. This might help make some design decisions.

Well, in one word, I'm a bit lost as for what to do, now.

WDYT?
Vincent

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

["J.Pietschmann" <j3...@yahoo.de>]

Vincent Hennebert wrote:
> Note also that TeX implemented best-fit for page-breaking only because
> of limited computation resources at that time (you know, those good old
> 80's).

Given the complaints on the lists about FOP memory usage, limited
computation resources seem to still be an issue... :-)

J.Pietschmann

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

Hi,

On Fri, Aug 11, 2006 at 04:17:15PM +0200, Vincent Hennebert wrote:
> 2006/8/11, Jeremias Maerki:
> >Are you sure that it's "much" worse? Note that even TeX uses best-fit
> >for page breaking.
> 
> Oh yes I'm sure ;-) It's a common complaint from users of the LaTeX
> world that figures are placed in a weird manner. There are plenty of
> parameters to tweak the output by hand, but this doesn't always give
> satisfying results. And given that manual intervention isn't really an
> option in the FO world...
> Note also that TeX implemented best-fit for page-breaking only because
> of limited computation resources at that time (you know, those good old
> 80's).

IIUC, LaTeX has a two-layer page break algorithm. First it lets TeX do
its page breaking, then in macro language it considers the result and
may ask TeX to do another pass over the page. It can request several
passes over each page. I have never studied it in any more detail.

> >Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this.
> >Best-fit will most likely replace total-fit because of the additional
> >features we can cover. If that means some drawbacks on things like
> >footnote placement that could be acceptable if the drawbacks are not too
> >great. ATM, I cannot estimate the impact of the change. Too bad we don't
> 
> Well, to me switching to best-fit is out of the question. Total-fit is a
> killer feature for technical documents with lots of figures and
> footnotes (the current implementation is already better than Xep...).
> This would give Fop a big advantage over concurrent implementations.
> 
> Rather, we might consider implementing both strategies. Ideally there
> would be an option in the config file ( "optimize-for-books" vs
> "optimize-for-fancy-layouts" or something like that). The generation of
> Knuth elements would be the same, only the breaking algorithm would
> differ. But abandoning total-fit is not an option, IMO. Moreover...

I agree with you. I would be really sorry to see the total fit
algorithm be abandoned in FOP.

> >I would not consider it a bad move if you concentrated the rest of your
> >time of the GSoC on the before-floats and footnotes, especially if it's
> >unlikely that you can finish side-floats in time and if the switch from
> >total-fit to best-fit hangs in the air. Even without an actual
> >implementation the groundwork for a side-float implementation in form of
> >some very good documentation is a very satisfying result. I would
> >consider the goals of the GSoC project met. It might be good to add some
> >best-fit-specific comments, though.

I am just reading through your side floats page. It is impressive. It
is indeed a good result for the GSoC project. It was clear from the
start that this would be a challenge of unknown severity.

Regards, Simon

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

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

[Vincent Hennebert <vh...@gmail.com>]

2006/8/11, Jeremias Maerki:
<snip/>
> > In some situations, a best-fit approach could even produce better
> > results, as we would have the possibility to consider the differing of a
> > side-float. But it is well-known that best-fit may be much worse than
> > total-fit regarding before-floats and footnote placements.
>
> Are you sure that it's "much" worse? Note that even TeX uses best-fit
> for page breaking.

Oh yes I'm sure ;-) It's a common complaint from users of the LaTeX
world that figures are placed in a weird manner. There are plenty of
parameters to tweak the output by hand, but this doesn't always give
satisfying results. And given that manual intervention isn't really an
option in the FO world...
Note also that TeX implemented best-fit for page-breaking only because
of limited computation resources at that time (you know, those good old
80's).


> > Looking at how tables are handled might give me some ideas for
> > side-floats, but this would require some time and there isn't much left
> > now.
> >
> > I also have some ideas for improving the handling of before-floats and
> > footnotes, and I'd like to implement them while I have time and it's
> > still fresh in my memory.
> >
> > The implementation I propose on the Wiki page has its limitations but
> > should work in most cases. This might give a basis for further
> > improvements.
> >
> > I'm thinking about making a poll on fop-user to know what are their
> > expectations regarding side-floats, and which usage they would make of
> > them. This might help make some design decisions.
>
> That should certainly provide some interesting feedback.
>
> > Well, in one word, I'm a bit lost as for what to do, now.
>
> Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this.
> Best-fit will most likely replace total-fit because of the additional
> features we can cover. If that means some drawbacks on things like
> footnote placement that could be acceptable if the drawbacks are not too
> great. ATM, I cannot estimate the impact of the change. Too bad we don't

Well, to me switching to best-fit is out of the question. Total-fit is a
killer feature for technical documents with lots of figures and
footnotes (the current implementation is already better than Xep...).
This would give Fop a big advantage over concurrent implementations.

Rather, we might consider implementing both strategies. Ideally there
would be an option in the config file ( "optimize-for-books" vs
"optimize-for-fancy-layouts" or something like that). The generation of
Knuth elements would be the same, only the breaking algorithm would
differ. But abandoning total-fit is not an option, IMO. Moreover...

> have much theoretical reference material on using the Knuth approach on
> page breaking. Most of what exists today around page breaking is by M.F.
> Plass or worked out by us on our Wiki.

... I'm still hoping to find a solution compatible with the total-fit
approach. The glue/box/penalty model is simply not powerful enough to
represent tables, side-floats and the like. All we have to do is find
another model...


> I would not consider it a bad move if you concentrated the rest of your
> time of the GSoC on the before-floats and footnotes, especially if it's
> unlikely that you can finish side-floats in time and if the switch from
> total-fit to best-fit hangs in the air. Even without an actual
> implementation the groundwork for a side-float implementation in form of
> some very good documentation is a very satisfying result. I would
> consider the goals of the GSoC project met. It might be good to add some
> best-fit-specific comments, though.

Ok, will do.


> How does that sound?

Well, now I know what to do ;-) I'll first work on footnotes and
before-floats improvements. I'll also try to implement the simplified
solution for side-floats. Depending on the results I'll write the
suitable documentation.


Thanks!
Vincent

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

On 11.08.2006 13:26:51 Vincent Hennebert wrote:
> 2006/8/11, Apache Wiki:
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
> >
> > The following page has been changed by VincentHennebert:
> > http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats
> >
> > The comment on the change is:
> > Difficulties around side-floats
> 
> Ok guys, I've been searching for 3 days for a simple, elegant, powerful,
> effective, ligthweight solution to make the total-fit algorithm work
> with side-floats, but can't seem to find one. This issue is somewhat
> related to the one regarding differing available ipd in page sequences
> (solving one might help solve the other one, at least). There is also
> some similarity with tables, i.e., how to combine several "vertical"
> Knuth element lists into just one. Excepted that in the case of
> side-floats, we may choose several completely different solutions to
> place them. And this is a case-by-case decision: one time this will be
> better to differ the float, one other time to break it, one other time
> to compress it...
> 
> In some situations, a best-fit approach could even produce better
> results, as we would have the possibility to consider the differing of a
> side-float. But it is well-known that best-fit may be much worse than
> total-fit regarding before-floats and footnote placements.

Are you sure that it's "much" worse? Note that even TeX uses best-fit
for page breaking.

> Looking at how tables are handled might give me some ideas for
> side-floats, but this would require some time and there isn't much left
> now.
> 
> I also have some ideas for improving the handling of before-floats and
> footnotes, and I'd like to implement them while I have time and it's
> still fresh in my memory.
> 
> The implementation I propose on the Wiki page has its limitations but
> should work in most cases. This might give a basis for further
> improvements.
> 
> I'm thinking about making a poll on fop-user to know what are their
> expectations regarding side-floats, and which usage they would make of
> them. This might help make some design decisions.

That should certainly provide some interesting feedback.

> Well, in one word, I'm a bit lost as for what to do, now.

Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this.
Best-fit will most likely replace total-fit because of the additional
features we can cover. If that means some drawbacks on things like
footnote placement that could be acceptable if the drawbacks are not too
great. ATM, I cannot estimate the impact of the change. Too bad we don't
have much theoretical reference material on using the Knuth approach on
page breaking. Most of what exists today around page breaking is by M.F.
Plass or worked out by us on our Wiki.

I would not consider it a bad move if you concentrated the rest of your
time of the GSoC on the before-floats and footnotes, especially if it's
unlikely that you can finish side-floats in time and if the switch from
total-fit to best-fit hangs in the air. Even without an actual
implementation the groundwork for a side-float implementation in form of
some very good documentation is a very satisfying result. I would
consider the goals of the GSoC project met. It might be good to add some
best-fit-specific comments, though.

How does that sound?

Jeremias Maerki

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

On Fri, Aug 18, 2006 at 07:04:56PM +0200, Vincent Hennebert wrote:
> Hi Simon,
> 
> 2006/8/17, Simon Pepping:
> >Rule 7a is logically correct, but I would say that the rule simply
> >states that a start float should not stick out at the end side, even
> >if it is not the one that is flush with the start side. Then x + ipd
> ><= ipd(ref-area) follows even without the condition ipd <=
> >ipd(ref-area).
> 
> Hmmm. If the ipd of a float is greater than ipd(ref-area), then it /is/
> allowed to stick out at one side (end-side for start-floats, start-side
> for end-floats). On the contrary, if ipd <= ipd(ref-area), then the
> float is not allowed to stick out at any side. That's why there is the
> condition. Don't you agree?

I had not looked at it from that point of view. That makes sense.

> >> One issue is that some legal pagebreaks are unknown until paragraphs are
> >> laid out (because of widows/orphans, for example). So the "for each
> >> legal pagebreak" is not that simple and might involve some backtracking.
> >
> >Yes, there is a problem there. The solution could be as follows: When
> >the legal pagebreak is in a paragraph, it is also the considered legal
> >linebreak. It is tested whether this linebreak could end the last line
> >of the page.
> 
> And deactivate the node if it turns out that this linebreak corresponds
> to (e.g.) the next-to-last line of the paragraph? Hmmm, that could work.
> I'll think about that.

That is right, the layout on the following page might invalidate this
pagebreak. One can only know after the whole paragraph has been broken
into lines. Awkward.

Regards, Simon

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

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

[Vincent Hennebert <vh...@gmail.com>]

Hi Simon,

2006/8/17, Simon Pepping:
> > >Rule 1. Why does the rule not require not both x >= 0 and x + ipd <=
> > >ipd(ref-area), for both start and end floats, unless the float is
> > >wider than the ipd(ref-area)? In other words, why is rule 7 not
> > >required for any start and end floats?
> >
> > Hey, you're right. Ok, rule 1 is correct: a start-float may not stick
> > out of the start-edge of the ref-area, period. The constraint on the
> > opposite side is given by rule 7, which actually is badly phrased. More
> > precisely, the formal wording is not equivalent to the loose wording
> > given between parentheses. The loose wording is quite clear and
> > intuitive; the formal wording forgets the case of a float alone: it's
> > not because it is alone that it may stick out of the ref-area.
> >
> > Well, now that you've pointed it out this is pretty obvious... I've
> > reformulated this rule according this time to the loose wording. Tell me
> > if you don't agree.
>
> Rule 7a is logically correct, but I would say that the rule simply
> states that a start float should not stick out at the end side, even
> if it is not the one that is flush with the start side. Then x + ipd
> <= ipd(ref-area) follows even without the condition ipd <=
> ipd(ref-area).

Hmmm. If the ipd of a float is greater than ipd(ref-area), then it /is/
allowed to stick out at one side (end-side for start-floats, start-side
for end-floats). On the contrary, if ipd <= ipd(ref-area), then the
float is not allowed to stick out at any side. That's why there is the
condition. Don't you agree?


> Rule 7b: the conclusion does not follow. The argument should be that
> an end float should not stick out at the start side, so that x > =0.

Same here: x must be >= 0 unless ipd > ipd(ref-area).

Re-thinking of that, I think the normative wording of rule 7 actually is
correct, even if it doesn't say exactly the same thing as the
non-normative one; when coupled with rule 9, it becomes equivalent.
I think I'm going crazy.


> > >In 'Properties of the model': I do not see that rule 7 is satisfied.
> >
> > A start-float begins at the end-edge of the ref-area and is pulled along
> > this edge (which is like a wall). So by nature it may not stick out of
> > this edge.
> >
> > What the illustration attempts to show is that if previous start-floats
> > occupy too much place, then the new start-float will strike against
> > their after-edges (the start-guide) without being able to go beforer.
>
> I see now that the rules are satisfied. To show that it is only
> necessary to point out that it is satisfied by the initial position,
> and is not violated by subsequent movements. Whether it is stopped by
> the start guide is not relevant in this argument.

Well the illustration was making sense when rule 7 was written the
previous way. Now it could well be removed... unless I rewrite rule 7 as
previously.


> You say nothing about the end floats. The argument is of course the
> same.

Will add a word.


> > One issue is that some legal pagebreaks are unknown until paragraphs are
> > laid out (because of widows/orphans, for example). So the "for each
> > legal pagebreak" is not that simple and might involve some backtracking.
>
> Yes, there is a problem there. The solution could be as follows: When
> the legal pagebreak is in a paragraph, it is also the considered legal
> linebreak. It is tested whether this linebreak could end the last line
> of the page.

And deactivate the node if it turns out that this linebreak corresponds
to (e.g.) the next-to-last line of the paragraph? Hmmm, that could work.
I'll think about that.


Thanks,
Vincent

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

Vincent,

On Tue, Aug 15, 2006 at 09:32:14PM +0200, Vincent Hennebert wrote:
> Hi Simon,
> 
> >Vincent,
> >
> >This page represents a good piece of work.
> >
> >Then a comment on the rules:
> >
> >Rule 1. Why does the rule not require not both x >= 0 and x + ipd <=
> >ipd(ref-area), for both start and end floats, unless the float is
> >wider than the ipd(ref-area)? In other words, why is rule 7 not
> >required for any start and end floats?
> 
> Hey, you're right. Ok, rule 1 is correct: a start-float may not stick
> out of the start-edge of the ref-area, period. The constraint on the
> opposite side is given by rule 7, which actually is badly phrased. More
> precisely, the formal wording is not equivalent to the loose wording
> given between parentheses. The loose wording is quite clear and
> intuitive; the formal wording forgets the case of a float alone: it's
> not because it is alone that it may stick out of the ref-area.
> 
> Well, now that you've pointed it out this is pretty obvious... I've
> reformulated this rule according this time to the loose wording. Tell me
> if you don't agree.

Rule 7a is logically correct, but I would say that the rule simply
states that a start float should not stick out at the end side, even
if it is not the one that is flush with the start side. Then x + ipd
<= ipd(ref-area) follows even without the condition ipd <=
ipd(ref-area).

Rule 7b: the conclusion does not follow. The argument should be that
an end float should not stick out at the start side, so that x > =0.

> >In 'Properties of the model': I do not see that rule 7 is satisfied.
> 
> A start-float begins at the end-edge of the ref-area and is pulled along
> this edge (which is like a wall). So by nature it may not stick out of
> this edge.
> 
> What the illustration attempts to show is that if previous start-floats
> occupy too much place, then the new start-float will strike against
> their after-edges (the start-guide) without being able to go beforer.

I see now that the rules are satisfied. To show that it is only
necessary to point out that it is satisfied by the initial position,
and is not violated by subsequent movements. Whether it is stopped by
the start guide is not relevant in this argument.

You say nothing about the end floats. The argument is of course the
same.

> >Finally some thoughts on a possible algorithm:
> >
> >for each legal pagebreak
> >  for each active pagebreak node
> >    layout the page and calculate its demerits
> >
> >Laying out the page involves breaking each paragraph on the page into
> >lines; each legal linebreak/active linebreak node combination (that
> >is, each iteration in the two nested loops of the linebreak
> >calculation) is associated with a certain side float layout, and thus
> >the line widths for that case are known and the demerits can be
> >calculated.
> 
> One issue is that some legal pagebreaks are unknown until paragraphs are
> laid out (because of widows/orphans, for example). So the "for each
> legal pagebreak" is not that simple and might involve some backtracking.

Yes, there is a problem there. The solution could be as follows: When
the legal pagebreak is in a paragraph, it is also the considered legal
linebreak. It is tested whether this linebreak could end the last line
of the page.

Regards, Simon

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

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

[Vincent Hennebert <vh...@gmail.com>]

Hi Simon,

> Vincent,
>
> This page represents a good piece of work.
>
> First some nit picking regarding language:
>
> 'A, if X; B, else': change else -> otherwise (2x)
>
> 'We may choose to either differ a side-float, or ...': change differ -> defer

Thanks. Changed.


> Then a comment on the rules:
>
> Rule 1. Why does the rule not require not both x >= 0 and x + ipd <=
> ipd(ref-area), for both start and end floats, unless the float is
> wider than the ipd(ref-area)? In other words, why is rule 7 not
> required for any start and end floats?

Hey, you're right. Ok, rule 1 is correct: a start-float may not stick
out of the start-edge of the ref-area, period. The constraint on the
opposite side is given by rule 7, which actually is badly phrased. More
precisely, the formal wording is not equivalent to the loose wording
given between parentheses. The loose wording is quite clear and
intuitive; the formal wording forgets the case of a float alone: it's
not because it is alone that it may stick out of the ref-area.

Well, now that you've pointed it out this is pretty obvious... I've
reformulated this rule according this time to the loose wording. Tell me
if you don't agree.


> In 'Properties of the model': I do not see that rule 7 is satisfied.

A start-float begins at the end-edge of the ref-area and is pulled along
this edge (which is like a wall). So by nature it may not stick out of
this edge.

What the illustration attempts to show is that if previous start-floats
occupy too much place, then the new start-float will strike against
their after-edges (the start-guide) without being able to go beforer.


> Finally some thoughts on a possible algorithm:
>
> The algorithm should combine pagebreak and linebreak calculations in a
> single dynamic calculation:

Yes, I think we should try to find something like that.


> for each legal pagebreak
>   for each active pagebreak node
>     layout the page and calculate its demerits
>
> Laying out the page involves breaking each paragraph on the page into
> lines; each legal linebreak/active linebreak node combination (that
> is, each iteration in the two nested loops of the linebreak
> calculation) is associated with a certain side float layout, and thus
> the line widths for that case are known and the demerits can be
> calculated.

One issue is that some legal pagebreaks are unknown until paragraphs are
laid out (because of widows/orphans, for example). So the "for each
legal pagebreak" is not that simple and might involve some backtracking.

>
> It is just a rough idea. I have no clear picture what the linebreak
> calculation in combination with side floats looks like. I just have
> the feeling that it should be possible in principle. Obviously, it may

Yes. I think the biggest problem is to decide when to defer a float or
not. Otherwise, as new floats have no impact on already computed lines
the current line-breaking algorithm won't have to be too much reworked.

Of course, I'm not speaking of values other than "line" for the
intrusion-displace property. I don't even want to think about the other
values...


> be necessary to break a paragraph into lines several times, each time
> with a different side float layout. It will be necessary to store
> earlier linebreak calculations for a paragraph in a clever way, so as
> to avoid unnecessary recalculations for identical linewidths. Working
> this out into a realistic algorithm requires much more thinking.
>
> Regards, Simon

Thanks for your comments, Simon.

Vincent

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

Vincent,

This page represents a good piece of work.

First some nit picking regarding language:

'A, if X; B, else': change else -> otherwise (2x)

'We may choose to either differ a side-float, or ...': change differ -> defer

Then a comment on the rules:

Rule 1. Why does the rule not require not both x >= 0 and x + ipd <=
ipd(ref-area), for both start and end floats, unless the float is
wider than the ipd(ref-area)? In other words, why is rule 7 not
required for any start and end floats?

In 'Properties of the model': I do not see that rule 7 is satisfied.

Finally some thoughts on a possible algorithm:

The algorithm should combine pagebreak and linebreak calculations in a
single dynamic calculation:

for each legal pagebreak
  for each active pagebreak node
    layout the page and calculate its demerits

Laying out the page involves breaking each paragraph on the page into
lines; each legal linebreak/active linebreak node combination (that
is, each iteration in the two nested loops of the linebreak
calculation) is associated with a certain side float layout, and thus
the line widths for that case are known and the demerits can be
calculated.

It is just a rough idea. I have no clear picture what the linebreak
calculation in combination with side floats looks like. I just have
the feeling that it should be possible in principle. Obviously, it may
be necessary to break a paragraph into lines several times, each time
with a different side float layout. It will be necessary to store
earlier linebreak calculations for a paragraph in a clever way, so as
to avoid unnecessary recalculations for identical linewidths. Working
this out into a realistic algorithm requires much more thinking.

Regards, Simon

On Fri, Aug 11, 2006 at 01:26:51PM +0200, Vincent Hennebert wrote:
> 2006/8/11, Apache Wiki:
> >Dear Wiki user,
> >
> >You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop 
> >Wiki" for change notification.
> >
> >The following page has been changed by VincentHennebert:
> >http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats
> >
> >The comment on the change is:
> >Difficulties around side-floats

<snip>

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

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

[Vincent Hennebert <vh...@gmail.com>]

2006/8/15, Simon Pepping:
> Hi,
>
> One more thing. All your beautiful pictures are on your own web
> site. Would you mind if we copy the pictures to the home page of one
> of the committers on people.apache.org, and change the links on the
> Wiki page? That is a more permanent solution.

I fully agree. We may perhaps just wait for the end of the GSoC, as I
might create new ones or rework some until that.

Vincent

Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert

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

Hi,

One more thing. All your beautiful pictures are on your own web
site. Would you mind if we copy the pictures to the home page of one
of the committers on people.apache.org, and change the links on the
Wiki page? That is a more permanent solution.

Regards, Simon

On Fri, Aug 11, 2006 at 01:26:51PM +0200, Vincent Hennebert wrote:
> 2006/8/11, Apache Wiki:
> >Dear Wiki user,
> >
> >You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop 
> >Wiki" for change notification.
> >
> >The following page has been changed by VincentHennebert:
> >http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats

<snip>

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