(moved here from fop-users)

I've listed them in February: http://markmail.org/message/3kph7prfmiekbmgz
So far, I've only started adjusting a copy of the API adapter for FO
renderers that I'm using for all test harnesses. That's the second time
in a few months that I have to create a new adapter. Last time, it was
because of the backwards-incompatible change on PrintRenderer (the
FOUserAgent parameter). So now I have 3: for FOP <=1.0, FOP 1.1 and FOP
2.x.

What I have so far from working on the above is: The FopFactoryBuilder
just feels weird. I still haven't understood the real-life purpose of
that change. The o.a.f.apps.io package should really be o.a.f.io (or
util.io). I don't like the dependency from the fonts and pdf packages
into FOP's outer API. At least twice in the past did I have to defend
similar dependencies from creeping in. And I'll have to see how I handle
the base URI business.

If I ever decide to switch back to Trunk (rather than continue using my
private OSGi-enabled fork), dealing with the URIResolver business is
going to be crucial for me. I do URI resolution through URIResolvers
literally everywhere, not just around FOP. Hopefully, URIResolver can
somehow be adapted to ResourceResolver without losing too much
functionality. At least OSGi makes it a lot more bearable to deal with
API changes between versions if the metadata is done right. Too bad for
those stuck in JAR hell.

Anyway, I guess we can have endless arguments about this. I don't have
time to hold them (which is why I didn't put my veto on the API changes),
so I should really just shut up and go back into my corner.

Jeremias Maerki

PS: don't forget MultiFileRenderingUtil if you want to get rid of
java.io.File.


On 26.07.2012 20:17:17 mehdi houshmand wrote:
> I appreciate that there are inconveniences, but if you're just looking for
> backwards compatibility, the changes should be, for the most part, fairly
> minor.
> 
> I'm sorry we haven't been able to convince you of the benefits of the
> changes, that's on me as the lead on this. I'm not sure really what else I
> can do to convince you, if you have specific concerns that we could address
> then I'd be happy to see if we can come to some sort of compromise. You
> talk about a java.xml.transform.URIResolver interface, are there any other
> things you'd like to see?
> 
> On 26 July 2012 17:15, Jeremias Maerki <d...@jeremias-maerki.ch> wrote:
> 
> > That's not quite true. That worked perfectly before by setting your own
> > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
> > SAXSource) containing an SVG image that you've dynamically built based
> > on some data (think charts). With the new approach, you have to
> > serialize that XML to a stream (buffered in memory or on disk) which
> > costs performance. Not a very common use case, I know, but we're talking
> > possibilities that are going away with the API changes.
> >
> > Previously, you could use Apache XML Commons Resolver for XML catalog
> > functionality. Now you probably have to write an adapter from
> > URIResolver to ResourceResolver (haven't had time to try that, yet). A
> > convenience adapter is missing.
> >
> >
> > Jeremias Maerki
> >
> >
> > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
> > <snip/>
> > > Btw... it's really nice that all data is loaded now through the new URI
> > > resolver. In the near future I'd like to use a custom scheme (e.g.
> > > myscheme://imageid) in order to load images instead of using HTTP. That
> > > wouldn't be possible without your change. So thanks!
> > <snip/>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
> >
> >

Reply via email to