xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Creating combined element lists for a table row from cell element lists
Date Tue, 22 Mar 2005 12:58:37 GMT
At first, I thought this wouldn't be difficult for easy cases but it
gets harder very quickly. Since the Wiki is currently served from the
backup servers in Amsterdam and therefore is read-only, I'll post here
on the list.

A simple example first:

<fo:table-row>
  <fo:table-cell line-height="15pt" id="cell1">
    <fo:block>block1</fo:block>
    <fo:block>block2</fo:block>
    <fo:block>block3</fo:block>
  </fo:table-cell>
  <fo:table-cell id="cell2">
    <fo:block>
      <fo:external-graphic src="something" 
        block-progression-dimension.minimum="15pt" 
        block-progression-dimension.optimum="30pt" 
        block-progression-dimension.maximum="45pt"/>
    </fo:block>
  </fo:table-cell>
</fo:table-row>

Cell1 list:
1) box w=15000
2) penalty w=0 p=0
--legal break
3) box w=15000
4) penalty w=0 p=0
--legal break
5) box w=15000
--cut-off point
6) penalty w=0 p=INF
7) glue w=0 y=INF z=0
8) penalty w=0 p=-INF flagged

Cell2 list:
1) box w=30000
2) penalty w=0 p=INF
3) glue w=0 y=15000 z=15000 (stretch for previous box)
--cut-off point
4) penalty w=0 p=INF
5) glue w=0 y=INF z=0
6) penalty w=0 p=-INF flagged

Creating a combined element list here is easy when I omit stretch and
shrink values:

step list between Cell1 and Cell2:
0, 15000, 30000, 45000

(the step list represents the dotted green lines on the graphic on
http://wiki.apache.org/xmlgraphics-fop/TableLayout)

combined list for row without stretch/shrink:
1) box w=15000 [C1: 1-2] [C2: empty]
2) penalty w=0 p=0
3) box w=15000 [C1: 3-4] [C2: 1-3]
4) penalty w=0 p=0
5) box w=15000 [C1: 5-5] [C2: empty]

-------------------------------------------------------------

So let's just complicate things a lot... :-)

<fo:table-row>
  <fo:table-cell line-height="15pt" id="cell1">
    <fo:block>block1</fo:block>
    <fo:block>block2</fo:block>
    <fo:block>block3</fo:block>
  </fo:table-cell>
  <fo:table-cell id="cell2a">
    <fo:block>
      <fo:external-graphic src="something" 
        block-progression-dimension="33pt"/>
    </fo:block>
    <fo:block line-height="8pt" font-size="8pt">Caption for the above image</fo:block>
  </fo:table-cell>
</fo:table-row>

Cell2a list:
1) box w=33000
2) penalty w=0 p=0
--legal break
3) box w=8000
--cut-off point
4) penalty w=0 p=INF
5) glue w=0 y=INF z=0
6) penalty w=0 p=-INF flagged

step list between Cell1 and Cell2a
0, 15000, 30000, 33000, 41000, 45000

There are suddenly a lot more possible break points.

I thought I could come up with a combined element list for this one, too,
but so far I haven't managed. For those who want to join the mind game,
here are the expected results from the broken lists:

break at first legal break:
Part 1 (height -> 15):
Part 2 (height -> 41):

break at second legal break:
Part 1 (height -> 30):
Part 2 (height -> 41):

break at third legal break:
Part 1 (height -> 33):
Part 2 (height -> 15):

break at fourth legal break:
Part 1 (height -> 41):
Part 2 (height -> 15):

no breaks:
Part 1 (height -> 45):

---------------------------------------------------

An alternative approach might be to do create "combined stretch boxes"
(actually box+pen(inf)+glue)

Cell1, combined stretch box: w=45000 y=30000 z=0
Cell2, combined stretch box: w=30000 y=15000 z=15000
Cell2a, combined stretch box: w=41000 y=8000 z=0

The combined stretch box for the whole row is easily calculated:

row combined stretch box in both cases (2 and 2a) is:
w=45000 y=30000 z=0

The LM tries to fit as much as possible into the available area (similar
to block-container with fixed BPD). The rest that doesn't fit at the end
is deferred for the next page where a new combined stretch box is
calculated. The consequence of this is the loss of look-ahead
possibility, since the combined stretch box doesn't know how much can
really fit on the previous page, and a new block list needs to be built.

A point I still have to think about for both approaches is how exactly
to handle row spanning, although I suspect it'll be easier for the first
approach.

I hope this is understandable. Additional ideas welcome...

Jeremias Maerki


Mime
View raw message