Jeremias Maerki [mailto:[EMAIL PROTECTED]:
Concerning the proposed TLPs I'm wondering if FOP and Batik shouldn't go together somehow. Both projects deal with XML to graphics conversions. FOP currently has 2 Batik Transcoder implementations (additional output formats for Batik: PDF, PS/EPS). So there is some kind of overlap which needs to be dealt with sooner or later. One possibility is to move the transcoders over to Batik but parts of them are FOP-specific so both projects should somehow be able to work on the common code. Moving these out of FOP still means a dependency on FOP's PDF, PostScript and font support code. These might need to be separated into "Commons" projects to be accessible to both projects and to ensure compatibility and cooperation.
Andreas L. Delmelle <[EMAIL PROTECTED]> wrote:
I agree, and don't want to come across as greedy here, but when it comes to
use-cases, fact remains that you can have XSL-FO w/ embedded SVG, but not
the other way around.
True, but SVG was designed to be embedded in another document. How are you going to deal with master pages etc if you try and embed XSL-FO in SVG? I'm not saying it couldn't be done but it would involve inventing stuff that is in neither of the two specifications (this is something that I find is generally a bad idea unless you are an active participant in the standards groups and are in a position to advance the standard[s]).
XSL-FO is designed as a container language so I don't think it makes sense, in general, to talk about embedding XSL-FO in SVG. That said the Batik architecture is extremely extensible, there would be no problem with registering bridges for XSL-FO tags and building a FOP rendering tree within the SVG tree - assuming you could make sense of what that XSL-FO subtree should look like.
(and for that matter: AFAICT XSL-FO can be rendered to
SVG, but not the other way around... this could, of course, change if the
two projects in question were merged somehow)
Short of just generating a small XSL-FO wrapper around the SVG content, how are you going to rendering SVG into XSL-FO? AFAIK there is no way to draw a poly-bezier or gradient in XSL-FO - you have to use SVG or some other image format to do this. Conversely, SVG has quite advanced text rendering capabilities. In other words the _rendering_ model of SVG is AFAIK a strict super-set of XSL-FO, with respect to layout SVG is much poorer than XSL-FO.
To put this another way SVG is a 'lower level' tool than XSL-FO. In many ways SVG is just a XML based rendering API, XSL-FO is a document format, so I consider it quite natural that the relationship is asymmetrical.
On top of that, judging solely from user-list traffic, [...] I definitely see this as a pointer to the wideness of usage.
I fail to see how this has any bearing on the decision to merge or
not (other than if we merge Batik users will be swamped by all this FOP traffic - a 33% increase is very different from a 400% increase in
mail volume - people will drop the ML I am certain)
I certainly support the idea of integrating the two projects one way or
another.
As do I, but I don't think it is a good idea to totally merge two completely independent standards implementations. If we could come up with a good name for a merged TLP with Batik and FOP under it that would probably be fine with me ( graphics? rendering? display?). This may be what you had in mind but your mention of the merged users list makes me think otherwise.
Another huge issue here is that for all intents and purposes static content rendering is done for Batik. All the work needed in Batik is for supporting dynamic documents. This is something FOP doesn't begin to think about - and FOP developers essentially don't benefit from and hence are not likely to contribute to.
I agree that the current situation with the transcoders is very problematic, I've even put together some ideas on what to do about it in the past. The correct solution I think is to separate out all the Graphics2D implementations (SVG, PDF, PS) into a separate common project and let both projects draw on that.
Right now the biggest issue is that the PDF/PS stuff is deeply ingrained in FOP due to Font stuff. IMHO this means that the Font stuff should either be made pluggable (so FOP can extend the base PDF font stuff) or totally separated from FOP so anyone who want's to use the PDF graphics can do so without FOP. The SVG Graphics2D is already essentially independent of the rest of Batik (there are some dependencies on utility/constant classes).
As I understand, there's a bunch of talented developers at
batik-dev, so I would certainly welcome a closer cooperation between the two
teams.
Right now I am the only active committer for Batik, and in 2004 I currently have no 'work time' allocated for it. As a result I don't want to make a huge fuss as it is unclear how much I will be able to contribute to implementing what ever the final decision is. It is also for this reason that I would actually prefer Batik not to have it's own TLP (as I would imagine this would require significant additional overhead).
In the long term, I think it would also be a benefit for the two specs (SVG / XSL-FO), if they become more and more directed towards combined usage, making SVG users aware of the possibilities of XSL-FO and vice versa. A combined user-list might be a good starter...
I think a combined user-list would be a disaster. In general I think the people who need to know about SVG get told about Batik and the people who need to know about XSL-FO get told about FOP if they wander into the wrong group.
