Yes, if you changed IF on me I'd need to know. I embed postscript commands in 
headers and page sequences. 

That said - if you are talking the java side of it versus the file format 
itself that doesn't affect me (but of course it may others) 


Martin Edge

On 04/04/2012, at 5:54 AM, Jeremias Maerki <> wrote:

> Glenn,
> I see the IF API as an advanced use case for FOP. I've realized from the
> beginning that the IF might have to mature over time and that requires
> changes. My main concern in the whole discussion is stability for the
> large majority of FOP's users who just rely directly or indirecly (in
> the case of XML editors and such) on relatively easy upgrades,
> especially if FOP can one day be released more often (with an easier
> release process).
> Just a thought loosely related to this: maybe we should introduce a
> "version" attribute on the root element to indicate the version of IF
> XML format so people can deal more easily with that.
> Maybe there should be a registry of FOP's APIs and the stability policy
> for each.
> On 02.04.2012 17:15:58 Glenn Adams wrote:
>> On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki 
>> <>wrote:
>>> There must be a really, really good reason to change the frontmost
>>> public API of FOP in a backwards-incompatible way. Changing the API will
>>> cause considerable work for all users when they upgrade. We must not do
>>> that on a whim.
>> Would you consider a minor, but substantive technical change to the IF
>> APIs, specifically, to IFPainter, to require a revision of the major
>> version? I ask this because one of the arguments to IFPainter.drawText()
>> has been changed from int[] to int[][] in the recent complex scripts merge.
>> In other words, are the IF public APIs to be considered part of the formal
>> public FOP API that is subject to version control rules?
>> Do we have a precise list of which APIs are (or should be) subject to such
>> rules?
> Jeremias Maerki

Reply via email to