Re: Customer requirement #1: Decrease font size

On 24 February 2013 00:50, Arved Sandstrom <> wrote:

>> Example please Arved.
>> 1. What you want to achieve by provision of such an api
>> 2. How the user (stylesheet writer) uses such an API
>> 3. How that api interacts with the formatter please.
>> 4. How the API is 'reached' from an xsl-fo stylesheet?

> Covering all the bases, Dave. Right now, considering the spec only and not
> any vendor enhancements, we control the formatter solely through FO XML. If
> the formatter exposed such an API, it could be programmatically controlled
> by a client app, which would receive events that it has registered for, and
> be able to act on them.
> How would a stylesheet writer use such an API? They wouldn't. But a user
> writing a programmatic client would. Both could be combined.
> The API *is* the formatter, just a different interface to it.
> The advantage of the API is that, properly designed, it offers more
> opportunities to control your formatting run and finetune output. You do as
> much as you can with FO XML, because the XML (DTDs/schemas properly) and
> XSLT that produce that FO are self-documenting. But you will never be able
> to anticipate every case with just FO.

Thanks, that shows the mechanics of it.
My immediate reaction is that this is a step away from declarative control?

Next question please.
So now I have an FO stylesheet and some code?
*What* might I do with it, other than request the formatter to format it?
Do I have to request it to format this block (by id?), then that one,
then that one?
I can't see any useful addition to the current workflow from this approach.

Still unclear as to the advantage of this approach Arved?


Dave Pawson
Docbook FAQ.

Received on Sunday, 24 February 2013 07:30:09 UTC