I suggest to add 2 more classes to what is considered a public API.

1. org.apache.fop.render.intermediate.IFException
This is obvious. Let's add it even though nobody will probably make there any 
backwards incompatible change.


2. org.apache.fop.render.intermediate.util.IFConcatenator
It makes no sense including the IFSerializer class and leaving out the class 
that reads FOP IF files and creates the final output format. 
This is used at least in embedding.intermediate.ExampleConcat.java


Alexios Giotis





On Jan 27, 2012, at 1:23 PM, Chris Bowditch wrote:

> On 25/01/2012 14:59, mehdi houshmand wrote:
> 
> Hi Mehdi,
>> I've spent some time looking through the examples and the
>> documentation above and I think the classes listed below are all the
>> classes necessary for most the use-cases and thus should be considered
>> the public API.
>> 
>> org.apache.fop.apps.*
>> org.apache.fop.fo.FOEventHandler
>> org.apache.fop.fonts.FontManager
>> org.apache.fop.events.EventListener
>> org.apache.fop.events.Event
>> org.apache.fop.events.model.EventSeverity
>> org.apache.fop.render.RendererFactory
>> org.apache.fop.render.intermediate.IFDocumentHandler
>> org.apache.fop.render.intermediate.IFParser
>> org.apache.fop.render.intermediate.IFUtil
>> org.apache.fop.render.intermediate.IFSerializer
>> org.apache.fop.render.intermediate.IFContext
>> 
>> This would mean deprecating
>> o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not
>> mistaken) this is legacy code to bind a MIME type to IF output.
>> Obviously I would also give instructions to use the IFDocumentHandler
>> implementation. Also, while we're at it, the IFDocumentHandler method
>> isn't described on the link above, so I'll try and put some
>> information there as well.
> 
> Thanks for preparing the list of classes that form the public API. I have 
> chcked the code that we use to embed FOP and it's all present in the above 
> list. A shame that its necessary to use classes from render.intermediate in 
> order to go FO->IF->PDF. In an ideal world those classes should be in a top 
> level intermediate package or a sub package of apps, but that won't be easy 
> to change now!
> 
> +1 to adding the above list to the website so we now have a clear definition 
> of what is part of the API and what is not.
> 
> The changes you propose to the move foUserAgent to the Renderer constructors 
> do not affect any of the above API classes so +1 to commit those too.
> 
> Thanks,
> 
> Chris
> 
>> 
>> I plan to put this information on the website, so please feel free to
>> discuss if you have any questions and/or wish to make amendments.
>> 
>> Mehdi
>> On 24 January 2012 19:36, Glenn Adams<[email protected]>  wrote:
>>> On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebert<[email protected]>
>>> wrote:
>>>> I would consider to be part of the public API the code that is present
>>>> on the following page:
>>>> http://xmlgraphics.apache.org/fop/trunk/embedding.html
>>>> 
>>> I agree. We should distinguish between APIs documented as being explicitly
>>> part of the embedding APIs and other public interfaces/members not
>>> documented as such.
>>> 
>>> Also, it is probably good to review, at least during every release, whether
>>> the embedding API documentation is correct and complete.
>> 
> 

Reply via email to