Re: Customer requirement #1: Decrease font size

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 

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.

I'm not sure I see a backwards compatibility problem issue here. If FO 
2.x (and 3.x and so forth) change then you need stylesheets versioned to 
those levels. A stylesheet written for 1.0 or 1.1 and designated as such 
has to get processed at that level. Am I missing something?

Returning to the programmatic APIs, I see a lot of advantages to that 
approach. It's amenable to incremental support by an implementation. 
Build out the API first that supports querying on formatting progress, 
which in theory affects nothing. Then tackle feedback requirements one 
by one or in manageable related subsets.

In fact if the notion of programmatic APIs was there from the outset, if 
someone preferred to specify these new features entirely in XML FO, the 
*implementation* could process these new feedback FO objects - 
internally - through the same interface. Exactly the same behaviour.


On 02/21/2013 10:34 AM, Tony Graham wrote:
> On Tue, February 19, 2013 2:19 pm, Dave Pawson wrote:
> [ SNIP ]
>> As regards backwards compatibility, IMHO that is not an issue?
> Backwards compatibility of what w.r.t. what?  Patrick's solution isn't
> backwards compatible with anything, and knowledge of its existence
> galvanised a subset of the people here to want to talk about more feedback
> within XSL formatting.  There's a whole spectrum of ways that what we
> produce could be incompatible with XSL-FO 1.1, and if we tried we could
> probably find several ways to cheese off existing XSL-FO users by making
> their existing stylesheets not work.
> If copyfitting, et al., becomes the killer app for XSL-FO, then backwards
> compatibility wouldn't matter, but we've already heard from Ken and we
> already know that there's a class of users for whom the output takes as
> many pages as it takes.  There's other expressed requirements such as #9,
> "Ability to modify label field width in a single list when labels are
> large.", that would be useful to the as-many-pages-as-it-takes users, but
> I can't see them upgrading for that if it breaks the rest of their work.
> Is there any consensus on the importance of backwards compatibility and
> the threshold for when a feature is important enough to justify being
> backwards incompatible?
> Regards,
> Tony.

Received on Saturday, 23 February 2013 13:43:26 UTC