Re: Customer requirement #1: Decrease font size

On 02/23/2013 10:48 AM, Dave Pawson wrote:
> On 23 February 2013 13:42, Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
>> Myself I hadn't thought that what we're talking about for formatting
>> feedback needs to be handled only (or at all) with formatting objects in
>> XML.
>>
>> It seems to me that for the larger formatting problem, that implementation
>> requirements could be a mix of support for XML-based FO and also for
>> programmatic access (various language APIs). This would all still be
>> specification stuff.
>
> 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?
>
> I can't see what you're getting at?
>
> regards
>
>
>
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.

Think streaming XML parser for a related technology.

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.

Arved

Received on Sunday, 24 February 2013 00:50:50 UTC