svn commit: r426029 - /xmlgraphics/batik/trunk/sources/org/apache/batik/transcoder/SVGAbstractTransc

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 ;)

deweeseapache.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-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org

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:heycamjabber.org  ▪  ICQ 26955922  ▪  MSN cammcc.id.au

------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org