Re: [xsl] adjust width of block to previous block

Subject: Re: [xsl] adjust width of block to previous block
From: "Tony Graham" <tgraham@xxxxxxxxxx>
Date: Fri, 15 Jul 2011 18:28:41 +0100 (IST)
On Fri, July 15, 2011 5:58 pm, G. Ken Holman wrote:
> At 2011-07-15 17:50 +0100, Tony Graham wrote:
>>On Fri, July 15, 2011 4:07 pm, Mathis Mvrke wrote:
>> > I don't know how to adjust the width of a next block to the previous
>> > block. I have an external graphic in a block and want the next block
>> > to have the same size as the block containing the external graphic.
>>Put them both in a fo:block-container with 'inline-progression-dimension'
>>set to the width of the graphic, which you are already using to set
>>'content-width' on the fo:external-graphic.
> But I saw that the input width attribute was
> optional and the comment at the top talked about
> the width being "dynamic" (which I interpreted as "not known").

Hence the 'trickier' option.

>>If FOP supported 'table-layout="auto"', then you would have had another
>>option by using a table to contain the graphic and caption.
> In my experience relying on "auto" hasn't been
> very helpful because different vendors interpret
> differently what to do with the width of
> columns.  As I mentioned in my post regarding a
> side float, if the text of the caption of the
> graphic is rendered wider than the width of the
> graphic, then the table cell might simply stretch.

The 'table-layout="auto"' option would, like the fo:block-container
option, require setting the width, this time of the fo:table, to something
narrow and relying on the formatter to work at keeping the width of the
formatted table to the minimum possible.  You'd also put the graphic and
the caption in separate cells to maximise the chance that the formatter
won't make the table wider than the graphic.

An implementation of the CSS2 automatic table layout algorithm [1] would
do what's wanted, but that's non-normative even for CSS2.

Both ideas are in the realm of a "Hail Mary pass" [2] to the formatter
since there is both leeway over .optimum vs .maximum and non-normative
algorithms in the specs.

Note also that the requirements for XSL FO 2.0 does include supporting
expressions containing information that's only available at formatting
time [3].


Tony Graham                                   tgraham@xxxxxxxxxx
Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
 --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
    XML, XSL FO and XSLT consulting, training and programming


Current Thread