Re: [xsl] Fitting content to a box in FO

Subject: Re: [xsl] Fitting content to a box in FO
From: Nic Gibson <nicg@xxxxxxxxxxxx>
Date: Tue, 19 Nov 2013 14:35:25 +0000
On 14 Nov 2013, at 12:1Hi Tony

Im planning to follow one of your suggestions. Its not a terribly rare
requirement is it?
Given that I have copies of FOP, RenderX and Antenna House to play with I
shall probably do whatever takes least time.


Tony Graham <tgraham@xxxxxxxxxx> wrote:

> On Thu, November 14, 2013 6:56 am, Kevin Brown wrote:
>> Tony gave some good answers. Possibly I get bonus points for doing this
>> many times already.
> IMO, the way for vendors to get bonus points is completely different.
> ...
>> In the XEP intermediate format, you can then easily get the actually
>> height
>> of the content and scale the content appropriately (proportionally) to fit
>> within the actual fixed page dimensions.
> That is essentially the first half of my second suggestion, if you
> substitute 'intermediate format' for 'area tree'.  Doing it once and
> scaling to fit the height -- no matter how you do the scaling -- is going
> to reduce the width in proportion, which isn't going to be optimal for a
> slide that's mostly text.
> If you do the first pass multiple times with the same width and differing
> font sizes, the text reflows to fit the width each time.  When you then
> pick the alternative that makes the best use of the height, you should
> find that it has fewer lines and a larger apparent font size compared to
> scaling down the original to fit the height.
> The extension from the Print and Page Layout CG [6] lets you automate that
> trying of differing font sizes within the one run of the XSLT processor to
> settle on the optimum font size (or whatever) [5] in one go.  You are more
> than welcome to implement similar for RenderX.
> Ideally this sort of copyfitting would be handled by the FO processor and
> standard across all FO processors.  Copyfitting is in the last XSL-FO 2.0
> draft [8] while CSS folks have only started looking at it [7], but given
> the vacuum around further development of XSL-FO, it looks like it will be
> another thing that's standardised in CSS rather than XSL-FO.
> Regards,
> Tony Graham                                   tgraham@xxxxxxxxxx
> Consultant                       
> Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
> --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
>    XML, XSL-FO and XSLT consulting, training and programming
>       Chair, Print and Page Layout Community Group @ W3C
> ...
>> From: "Tony Graham" <tgraham@xxxxxxxxxx>
>> Subject: Re: [xsl] Fitting content to a box in FO
> ...
>> The two-pass--all-FO solution -- as I describe at [3] -- would be run it
>> once with unconstrained height and get the area tree to work out how to
>> scale the slides.  For bonus points, you could generate an initial FO file
>> that has every slide at a range of font sizes and image magnifications,
>> get
>> the area tree, and work out which font size works best for each slide.
>> The bleeding-edge solution [4] is to use FOP and the FOPRunXSLTExt [5]
>> extension from the Print and Page Layout CG to iteratively adjust the
>> font-size, etc., and run the FO processor from within your XSLT transform
>> until you have the optimal settings, which you then include in the 'real'
>> FO output.  For bonus points of a different kind, you could port the
>> extension to Antenna House's or RenderX's Java interface and contribute
>> that
>> back to the CG.
> ...
>> [5]
>> [6]
> [7]
> [8]

Corbas Consulting / @CorbasLtd
Digital Publishing Consultancy and Training, +44 (0)7718 906817/+44 (0)1273 930765

Current Thread