xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject RE: Draft discussion of Federation proposal
Date Mon, 05 Jan 2004 14:57:50 GMT
Hi Andreas, Jeremias,

Jeremias Maerki [mailto:dev.jeremias@greenmail.ch]:

>> 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 <a_l.delmelle@pandora.be> 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.




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message