You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by Apache Wiki <wi...@apache.org> on 2006/09/15 09:20:34 UTC

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

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:
Move the pictures to a more permanent location

------------------------------------------------------------------------------
  
  In such a coordinate-system, a side-float area is characterized by the (x,y) coordinates of its "start-before point", that is, the point of its allocation-rectangle (or border-rectangle, or padding-rectangle, or content-rectangle) which is at the intersection of the start-edge and before-edge.
  
- http://atvaark.dyndns.org/~vincent/side-floats_coordinate-system.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_coordinate-system.png
  
  == Rules for Placing Side-floats ==
  Some definitions:
@@ -47, +47 @@

   10. if "clear" = "left", "start", "both", ∀ start-float' ≺ side-float, y > y' + bpd'
   if "clear" = "right", "end", "both", ∀ end-float' ≺ side-float, y > y' + bpd'
  
- Here's a [http://atvaark.dyndns.org/~vincent/side-floats.pdf pdf version] for those whose browser has difficulties displaying UTF-8 characters.
+ Here's a [http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats.pdf pdf version] for those whose browser has difficulties displaying UTF-8 characters.
  
  == Uncertainties ==
  At the beginning of section 9.5 of the CSS2 recommendation, it is loosely explained how floats should be placed, and it is said that the precise placement rules should be found in the description of the "float" property.
@@ -133, +133 @@

  
  There will also be one "start-guide", representing the afterest after-edge of start-floats, and one "end-guide", for the afterest after-edge of end-floats.
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-start.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-start.png
  
  Now let's suppose we want to place a new start-float; the idea is to place it at the after-end corner of the reference-area. Then we pull it toward the before-edge until it touches one of the guide lines.
  
  While continuing to pull towards the before, we will start pulling also towards the start; the float will progress along the jagged line until it is blocked; it has reached its final placement. The guide lines are updated as should be.
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float1_1.png
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float1_2.png
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float1_3.png
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float1_4.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float1_1.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float1_2.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float1_3.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float1_4.png
  
  Now we will place an end-float; there is no more place on the current line, so the float will be placed after the last placed start-float:
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float2_1.png
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float2_2.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float2_1.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float2_2.png
  
  Note that the before-guide no longer corresponds to the current line-area, as the last float has been placed afterer. Note also that there is a hole below the third end-float from the right: its after-edge no longer serves for the guide as there is an end-float placed to its start (left), whose after-edge is afterer. (This was the same case for the first start-float.)
  
  Let's place a new start-float:
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float3.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float3.png
  
  And then a new end-float:
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-float4.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-float4.png
  
  
  Side-floats are boxes which may allow some shrinking/stretching in the block-progression-dimension. Me may take advantage of this possibility to place floats which otherwise wouldn't fit on the page. On the figure below, the second start-float has the "clear" property set to "start":
  
- http://atvaark.dyndns.org/~vincent/side-floats_placement-shrink.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-shrink.png
  
  == Properties of the Model ==
  By nature, this model should respect all of the rules for side-floats placement:
@@ -174, +174 @@

   6. idem
   7. a start-float starts its movement at the end-edge of the ref-area, which acts like a wall, so it may not stick out of it (there will have to be a special handling for floats whose ipds are superior to the ref-area's ipd). If previous start-floats take too much place in the i-p-d, its movement towards the before will be stopped by the start-guide:
  
-  http://atvaark.dyndns.org/~vincent/side-floats_placement-rule7.png
+  http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_placement-rule7.png
  
   8.#8 the side-float is pulled towards the before as much as possible
   9. the side-float is pulled towards the start/end as much as possible, but after having been pulled towards the before
@@ -191, +191 @@

  
  The resulting layout may be quite different then, as may be seen on the following figure:
  
- http://atvaark.dyndns.org/~vincent/side-floats_page-break.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_page-break.png
  
  We may choose to either defer a side-float, or shrink it so that it fits on the page, or split it to put one piece on each page.
  
  We could try to combine in some way the informations about line-breaking as well as page-breaking. For each feasible line-break we would also store informations regarding page breaking: does it also represent a legal page-break? If yes, is it a feasible page-break? And then the following line is computed in two different situations: whether the previous line-break was also chosen as a page-break (in which case the available width is the ipd of the following page), or not (and the available width is the ipd of the current page).
  
- http://atvaark.dyndns.org/~vincent/mixing-line-page-breaks.png
+ http://people.apache.org/~jeremias/fop/vincent/SideFloats/mixing-line-page-breaks.png
  
  This situation leads to approximately doubling the Knuth nodes for the rest of the paragraph: one set for the case where the line is on the current page, one other set for the case where the line is put on the following page. Of course the nodes don't represent the same feasible breaks, as line widths are different. But there are approximately as many in each case.
  
@@ -212, +212 @@

   * a legal page-break inside a side-float would be considered only if it coincides with a normal line's legal page-break (also a minor issue);
   * and most of all, we would never consider to defer a side-float on a following page to permit a page-break. This might lead to very large chunks of text without any break possibility:
  
-  http://atvaark.dyndns.org/~vincent/side-floats_no-break-poss.png
+  http://people.apache.org/~jeremias/fop/vincent/SideFloats/side-floats_no-break-poss.png
  
  That said, such situations should be rather uncommon and this method should work in most cases. It might be a good solution for a first implementation.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org