You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by th...@kodak.com on 2006/07/27 15:10:41 UTC
Re: svn commit: r426029 - /xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.java
Hi all,
A little more about this commit. In the SVG 1.2 branch of Batik many
of the
'createBridgeContext' methods have had their signature changed. They
now take an 'SVGOMDocument'. This means that the versions provided
by the FOP transcoder aren't being called.
The correct fix is for the FOPTranscoder to provide an
SVG12BridgeContext
and provide the createBridgeContext methods that take the SVGOMDocument.
The first one is a bit tricky since the SVG12BridgeContext only exists in
'trunk'.
So then the issues comes down to:
1) Move the FOPTranscoder Batik baseline to the 'trunk' version of
Batik
- This is problematic since FOP can only bundle 'released'
jars
(although we may be having a release of Batik now that
Cameron
has implemented most of SMIL).
2) Provide the SVGOMDocument version of createBridgeContext but
only
return a '1.1' BridgeContext in all cases.
I think #2 is the right way to go for now (until Batik has another
release) as it appears
that the SVG12BridgeContext is mostly concerned with dynamic things.
Cameron can you think of anything off the top of your head that will
really
blow up if a 'static' SVG 1.2 document tries to use the base BridgeContext
(I suppose the onload stuff might not work properly).
Anyway, opinions ideas, rants ;)
deweese@apache.org wrote on 07/27/2006 06:29:14 AM:
> Author: deweese
> Date: Thu Jul 27 03:29:13 2006
> New Revision: 426029
>
> URL: http://svn.apache.org/viewvc?rev=426029&view=rev
> Log:
> Now calls old createBridgeContext method so the PDFTranscoder can insert
it's bridges
>
> Modified:
>
>
xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.java
>
> Modified:
>
xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.java
> URL: http://svn.apache.
>
org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.
> java?rev=426029&r1=426028&r2=426029&view=diff
>
==============================================================================
> ---
>
xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.
> java (original)
> +++
>
xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.
> java Thu Jul 27 03:29:13 2006
> @@ -299,6 +299,12 @@
> if (doc.isSVG12()) {
> return new SVG12BridgeContext(userAgent);
> }
> + // For SVG 1.1/1.0 docs call old signature createBridgeContext
> + // method (this allows FOP to register it's bridges).
> + return createBridgeContext();
> + }
> +
> + protected BridgeContext createBridgeContext() {
> return new BridgeContext(userAgent);
> }
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: svn commit: r426029 - /xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTranscoder.java
Posted by Cameron McCormack <ca...@mcc.id.au>.
Hi Thomas.
Thomas DeWeese:
> A little more about this commit. In the SVG 1.2 branch of Batik
> many of the 'createBridgeContext' methods have had their signature
> changed. They now take an 'SVGOMDocument'. This means that the
> versions provided by the FOP transcoder aren't being called.
>
> The correct fix is for the FOPTranscoder to provide an
> SVG12BridgeContext and provide the createBridgeContext methods that
> take the SVGOMDocument. The first one is a bit tricky since the
> SVG12BridgeContext only exists in 'trunk'.
>
> So then the issues comes down to:
> 1) Move the FOPTranscoder Batik baseline to the 'trunk'
> version of Batik
> - This is problematic since FOP can only bundle
> 'released' jars (although we may be having a release
> of Batik now that Cameron has implemented most of
> SMIL).
> 2) Provide the SVGOMDocument version of createBridgeContext
> but only return a '1.1' BridgeContext in all cases.
>
> I think #2 is the right way to go for now (until Batik has another
> release) as it appears that the SVG12BridgeContext is mostly
> concerned with dynamic things.
>
> Cameron can you think of anything off the top of your head that
> will really blow up if a 'static' SVG 1.2 document tries to use the
> base BridgeContext (I suppose the onload stuff might not work
> properly).
If it’s a static document, yeah I think there’s no problem, since
SVG12BridgeContext only adds functionality for dynamic documents (like
proper handling of events with sXBL). As soon as it is dynamic there
are a couple of places that cast the BridgeContext to
SVG12BridgeContext.
In the long run, I’m of the opinion that the separation between the
svg12 classes and the original ones should be removed. Since the SVG WG
want to change the meaning of the 'version' attribute in documents to
mean “you need a UA that supports at least this version to get full
funcionality from the document but it still might fall back otherwise”,
the distinction between SVG 1.1 and SVG 1.2 documents falls away mostly.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org