- From: Dave Pawson <dave.pawson@gmail.com>
- Date: Sun, 24 Feb 2013 07:29:40 +0000
- To: public-ppl@w3.org
On 24 February 2013 00:50, Arved Sandstrom <asandstrom2@eastlink.ca> 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? regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk
Received on Sunday, 24 February 2013 07:30:09 UTC