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 Cameron McCormack <ca...@aka.mcc.id.au> on 2005/01/20 05:08:43 UTC
Keeping SVG 1.2 code separate from SVG 1.1 code
Hi Thomas and others.
I'm still working on sXBL support for Batik and again I'm wondering
about how separate code for 1.2 features should be. A few particular
issues:
- What should be done for DOM 3 support? Should the existing classes
in org.apache.batik.dom be updated with DOM 3 methods and so on? Or
should separate DOM 3 objects only be created for version="1.2"
documents and DOM 2 objects created for version="1.1" documents? I
guess there will only be one set of org.w3c.dom interfaces, those
being the DOM 3 ones. (Isn't this going to make it difficult for
people to run Batik without messing around with bootclasspaths or
"endorsed standards override" jars, like with Xalan[1]?)
- I don't think I can properly separate sXBL DOM (such as all elements
having to implement NodeXBL) from the SVG DOM classes without much
code duplication. The easist thing (and what I've done so far) is
to extend from the Abstract* classes in org.apache.batik.dom to
sXBL capable DOM classes in org.apache.batik.dom.xbl. Then, I have
org.apache.batik.dom.svg.AbstractElement extend
org.apache.batik.dom.xbl.XBLElement. This does mean though that
version="1.1" documents will have sXBL DOM functionality.
- Since event flow works differently in the presence of sXBL, I found
the need to modify org.apache.batik.dom.events.AbstractEvent to
handle things like event retargetting and stopping, so that the
EventSupport class wouldn't be polluted with sXBL specific things.
If I were to keep this properly separate for version="1.2" documents
I would have to have different classes for DOMEvent, DOMUIEvent,
etc.
- In light of this message
http://lists.w3.org/Archives/Public/www-svg/2005Jan/0029.html
I think it would be difficult to handle documents whose version
changes if there is a particular DOMImplementation that is chosen at
document parse time.
Any thoughts?
Thanks,
Cameron
[1] http://xml.apache.org/xalan-j/faq.html#faq-N100CC
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Class PathParser
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Alice,
Alice Mello wrote:
> It seems like PathParser is ideal for me to use in order to parse a SVG
> file into a private text file with graph coordinates. But, I have no
> clue on how to use it.
> does anyone have an example?
Well the code in Batik that uses it is:
batik.bridge.SVGPathElementBridge lines 79-85
This makes use of the batik.parser.AWTPathProducer
class which does most of the work. The basic idea is
to subclass/implement the PathHander interface (Which
is what AWTPathProducer does). Then you pass your
subclass into the PathParser instance and finally
call 'parse' with your path data - this is what SVGPathElementBridge
does.
Good luck!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Class PathParser
Posted by Alice Mello <me...@media.mit.edu>.
Hello all,
It seems like PathParser is ideal for me to use in order to parse a SVG
file into a private text file with graph coordinates. But, I have no
clue on how to use it.
does anyone have an example?
Thanks a lot,
Alice
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Keeping SVG 1.2 code separate from SVG 1.1 code
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> Thomas DeWeese:
>
>> One option we do have available is to have DOM 3 methods
>>throw exceptions if we are processing a 1.1 document. This still
>>isn't great since you really want to pick these things up at compile
>>time (at least for Java - for JavaScript it doesn't matter much).
>>I suppose one could bundle DOM2 and SVG 1.1 jars that people could
>>compile against. What do you think?
>
> I don't know if there would be much demand for ensuring that Java
> programs people make use only SVG 1.1 features. Are there situations
> where SVG 1.1 only Batiks are installed that can't easily be upgraded
> (on web servers or something)? I don't think people will deliberately
> restrict themselves to SVG 1.1 features if the Batik they are using
> supports SVG 1.2.
You are correct that the number of people who are likely to
want/need this are small. So it probably makes sense to keep this
in mind if anyone ever asks about it, but not to bother including
the jars with Batik.
> As for throwing exceptions, this would be the easiest solution, but is
> checking for version for every 1.2-specific method too much overhead?
I would doubt it, but I don't really know DOM 3. It is possible
that something like 'nextSibling' (from DOM 2) might be fast enough
that the extra check would be noticed. However, I think in general if
the document stores an integer indicating 'version' the check should
be very quick relatively speaking.
>> BTW the xml-apis in JDK 1.5 is DOM 3 :/
>
> Is compilation or execution affected by this at all? (I haven't tried
> JDK 1.5.)
I don't think execution is affected (interfaces are funny as long
as you don't try and call an 'unimplemented' method you're OK). This
does make it impossible/very difficult to compile with the JDK 1.5
compiler, because the compiler does check that all methods are
implemented (otherwise the class needs to be marked as abstract) and
we don't implement all the DOM 3 methods. So you would have to do
something odd to get the DOM 2 xml-apis in the classpath before
the JDK's DOM 3 copy.
>> However I suspect that in the fullness of time it will be best to
>> just add NodeXBL to the 1.1 impl (*sigh*).
>
> The only XBL-ness in the SVG subclasses are in the SVGDOMImplementation and
> SVGOMDocument, to create XBL* objects.
What all is in the NodeXBL interface?
> A couple of other classes in there too, but they probably belong
> in the svg12 package (SVGOMCustomElement, SVGOMXBLTemplateElement).
Yes, these should probably be in the SVG12 package.
> What 1.1 elements behave differently in 1.2, if any?
Just about all of them, since the SVGLocatable interface was
expanded. Normally people would consider an implementation to be
in error if it allows calls to methods that aren't defined in the
specification it implements.
> Anyway, maybe you should weigh in to that thread with your opinion.
I'll do that.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Keeping SVG 1.2 code separate from SVG 1.1 code
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> One option we do have available is to have DOM 3 methods
> throw exceptions if we are processing a 1.1 document. This still
> isn't great since you really want to pick these things up at compile
> time (at least for Java - for JavaScript it doesn't matter much).
> I suppose one could bundle DOM2 and SVG 1.1 jars that people could
> compile against. What do you think?
I don't know if there would be much demand for ensuring that Java
programs people make use only SVG 1.1 features. Are there situations
where SVG 1.1 only Batiks are installed that can't easily be upgraded
(on web servers or something)? I don't think people will deliberately
restrict themselves to SVG 1.1 features if the Batik they are using
supports SVG 1.2.
As for throwing exceptions, this would be the easiest solution, but is
checking for version for every 1.2-specific method too much overhead?
> BTW the xml-apis in JDK 1.5 is DOM 3 :/
Is compilation or execution affected by this at all? (I haven't tried
JDK 1.5.)
> This is in fact potentially more manageable as ANT could be
> used to create two copies of dom.svg one where classes inherit from
> XBLElement and one where they inherit from AbstractElement (assuming
> that there is little or no XBL-ness in the SVG subclass). However
> I suspect that in the fullness of time it will be best to just add
> NodeXBL to the 1.1 impl (*sigh*).
The only XBL-ness in the SVG subclasses are in the SVGDOMImplementation and
SVGOMDocument, to create XBL* objects. A couple of other classes in
there too, but they probably belong in the svg12 package
(SVGOMCustomElement, SVGOMXBLTemplateElement).
> I'm a little less sure here, but given we added 1.2 to
> everything else unless there are significant 'incompatibilities'
> I'd be tempted to just have one set of event classes. I'm a little
> surprised that you don't need XBL stuff in EventSupport anyways.
Yeah, I was trying to keep it out of EventSupport, but on reflection I
probably will just have to use a subclass for 1.2 documents.
> I think the proposal that the 'version' attribute can be
> change (and modify document behavior) is ridiculous. What is the
> usecase? If it were free then fine but it will be far from free for
> all implementations (at the very least requiring a walk of the tree -
> looking for now invalid things) and there really isn't a single good
> usecase I can think of.
I guess it is a lot of work for something that nobody will ever do.
> Let's take the case of an existing reference to a node it
> suddenly needs to lose/gain it's SVG 1.2ness? seems silly to me.
I was trying to think of some cases where this would be troublesome.
Is it really a problem if DOM 3 methods exist on 1.1 DOM objects
(provided they throw exceptions)? Certain script could execute
differently by just checking if a function exists on the object or not.
But I guess if you are writing a 1.1 document and it refers to a DOM 3
method then any behaviour would be (strictly) acceptable -- if it is
a function reference or a the undefined value, it shouldn't make much
difference, practically.
What 1.1 elements behave differently in 1.2, if any?
Anyway, maybe you should weigh in to that thread with your opinion.
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Keeping SVG 1.2 code separate from SVG 1.1 code
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
Cameron McCormack wrote:
> I'm still working on sXBL support for Batik and again I'm wondering
> about how separate code for 1.2 features should be. A few particular
> issues:
Yes, all good questions. See answers inline. I'm still thinking
about possible alternate options, but right now they all seem pretty
horrible...
> - What should be done for DOM 3 support? Should the existing classes
> in org.apache.batik.dom be updated with DOM 3 methods and so on?
As you point out below the way W3C is doing it's interfaces I
don't think we have any choice here we will have to have DOM3 on
everything. It would have been nice if they had added the DOM3
methods by 'sub-interfacing' into a org.w3c.dom3 package. Since all
they specify is interfaces they could have used multiple inheritance.
I don't think it's a good idea to try and get 'tricky' with
classloaders (although as I understand it this can be done fairly
cleanly).
One option we do have available is to have DOM 3 methods
throw exceptions if we are processing a 1.1 document. This still
isn't great since you really want to pick these things up at compile
time (at least for Java - for JavaScript it doesn't matter much).
I suppose one could bundle DOM2 and SVG 1.1 jars that people could
compile against. What do you think?
BTW the xml-apis in JDK 1.5 is DOM 3 :/
> should separate DOM 3 objects only be created for version="1.2"
> documents and DOM 2 objects created for version="1.1" documents? I
> guess there will only be one set of org.w3c.dom interfaces, those
> being the DOM 3 ones. (Isn't this going to make it difficult for
> people to run Batik without messing around with bootclasspaths or
> "endorsed standards override" jars, like with Xalan[1]?)
>
> - I don't think I can properly separate sXBL DOM (such as all elements
> having to implement NodeXBL) from the SVG DOM classes without much
> code duplication. The easist thing (and what I've done so far) is
> to extend from the Abstract* classes in org.apache.batik.dom to
> sXBL capable DOM classes in org.apache.batik.dom.xbl. Then, I have
> org.apache.batik.dom.svg.AbstractElement extend
> org.apache.batik.dom.xbl.XBLElement. This does mean though that
> version="1.1" documents will have sXBL DOM functionality.
This is in fact potentially more manageable as ANT could be
used to create two copies of dom.svg one where classes inherit from
XBLElement and one where they inherit from AbstractElement (assuming
that there is little or no XBL-ness in the SVG subclass). However
I suspect that in the fullness of time it will be best to just add
NodeXBL to the 1.1 impl (*sigh*).
> - Since event flow works differently in the presence of sXBL, I found
> the need to modify org.apache.batik.dom.events.AbstractEvent to
> handle things like event retargetting and stopping, so that the
> EventSupport class wouldn't be polluted with sXBL specific things.
> If I were to keep this properly separate for version="1.2" documents
> I would have to have different classes for DOMEvent, DOMUIEvent,
> etc.
I'm a little less sure here, but given we added 1.2 to
everything else unless there are significant 'incompatibilities'
I'd be tempted to just have one set of event classes. I'm a little
surprised that you don't need XBL stuff in EventSupport anyways.
> - In light of this message
>
> http://lists.w3.org/Archives/Public/www-svg/2005Jan/0029.html
>
> I think it would be difficult to handle documents whose version
> changes if there is a particular DOMImplementation that is chosen at
> document parse time.
I think the proposal that the 'version' attribute can be
change (and modify document behavior) is ridiculous. What is the
usecase? If it were free then fine but it will be far from free for
all implementations (at the very least requiring a walk of the tree -
looking for now invalid things) and there really isn't a single good
usecase I can think of.
Let's take the case of an existing reference to a node it
suddenly needs to lose/gain it's SVG 1.2ness? seems silly to me.
> Any thoughts?
>
> Thanks,
>
> Cameron
>
> [1] http://xml.apache.org/xalan-j/faq.html#faq-N100CC
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org