[kepler-dev] Re: illustrator svg settings

John Reekie john.reekie at uts.edu.au
Sun Mar 13 05:39:50 PST 2005


Hi, as I recall, the issue with SwingWrapper was that events were not
being translated properly. There is a method in Graphics2D that can help,
but it is protected.

The current SVG parser was not intended to be a complete solution, it
was a simple but useful tool that (I believe) extended an earlier piece of
code that I wrote pre-SVG.

In the present situation, it seems to me that the best approach would be
to simply implement the Figure interface (or subclass AbstractFigure).
Make the paint() method use the SVG parser from Batik to render into
the Graphics2D object which is passed to paint(). I haven't looked but
I would think that Batik would be able to render into a Graphics2D.

Does this help? Please let me know. It would be nice to integrate more
extensive SVG support into Diva/Ptolemy.

JohnR


Edward A. Lee wrote:

>
> Matt:
>
> I agree that this would be a very nice solution, but it could be tricky
> to implement.  In theory, one can use SwingWrapper in Diva to wrap an
> an object.  Unfortunately, everyone who has tried to do so has run up
> against problems and has then given up...  I haven't tried myself,
> so I'm hesitant to try to finger the blame... The Diva architecture
> is by no means simple...
>
> I've cc'd John Reekie, author of Diva, in case he has suggestions
> or comments.
>
> One advantage of the approach we are using with the icon editor
> is that you can fairly easily animate icons.  Since the elements
> of an icon are parameters with parameters giving the color, size,
> etc., the visuals can easily be made a function of parameters in
> the model.
>
> Edward
>
>
> At 12:03 PM 3/8/2005 -0900, Matt Jones wrote:
>
>> Thanks for the update, Edward.  It suprises me a little that you are 
>> moving towards raster formats given that the ptolemy canvas needs to 
>> support such extensive rescaling operations while zooming.  I thought 
>> SVG was a nice solution to that, and we were planning on using it for 
>> all of our new icons.
>>
>> The problem, of course, is that Ptolemy doesn't support some of the 
>> basic SVG constructs such as group elements and path elements, among 
>> others, so creating the SVG icons from standard apps is hard. So I've 
>> been investigating what it would take to get the Batik SVG renderer 
>> installed in Ptolemy for more complete SVG support.
>>
>> Batik provides a Swing component 
>> (org.apache.batik.swing.svg.JSVGComponent) that can render SVG that 
>> looks very easy to use -- just create the component and pass it the 
>> SVG DOM (see links below).  However, its not clear how Swing 
>> components fit into the Diva framework.  Does the 
>> diva.canvas.toolbox.SwingWrapper class work (it doesn't seem to be 
>> referenced from any of our code)?  If so that might be a fairly 
>> simple way to handle it.  I've looked at the existing XMlIcon and 
>> SVGIcon classes and they seem harder to adapt because they are so 
>> closely tied into the Diva Figure framework using PaintedObject 
>> (which Diva docs say is deprecated anyways).
>>
>> What do you think?  Would SwingWrapper work?  If so, we might spend a 
>> bit of time getting it implemented.  Your recommendations are 
>> appreciated. Thanks,
>>
>> Matt
>>
>> Links
>> ------
>> JSVGComponent API:
>> http://xml.apache.org/batik/javadoc/org/apache/batik/swing/svg/JSVGComponent.html 
>>
>>
>> Batik JSVGCanvas tutorial:
>> http://xml.apache.org/batik/svgcanvas.html
>>
>>
>> Edward A. Lee wrote:
>>
>>> Note that we've been moving away from SVG for representing icons...
>>> I'm not sure that's what you are doing... The SVG supported for this
>>> is extremely limited, and it would be a fair amount of work to
>>> make it more complete.  We now use the icon editor instead, which
>>> supports basic graphic elements as attributes, and also supports
>>> gifs or jpeg images.
>>> Edward
>>> At 11:44 AM 3/7/2005 -0900, Matt Jones wrote:
>>>
>>>> Thanks, Laura.  This composite looks great.  The icons are all solid
>>>> colors and simple lines, so they should be able to be represented 
>>>> in the
>>>> simplified SVG that ptolemy supports.  Getting them into that format
>>>> might not be easy, however.  Illustrator, for example, makes extensive
>>>> use of SVG 'path' elements and group ('g') elements when writing out
>>>> SVG, which ptolemy doesn't support.  But we can get the developers to
>>>> get that stuff fixed, probably at a minimum creating a conversion
>>>> script.  It looks to me like we should be able to use the same SVG for
>>>> the canvas and the tree because they should scale ok.  I'm moving this
>>>> conversation onto the list so that the other Kepler developers are 
>>>> aware
>>>> of the issues.
>>>>
>>>> Matt
>>>
>>
>> -- 
>> -------------------------------------------------------------------
>> Matt Jones                                     jones at nceas.ucsb.edu
>> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
>> National Center for Ecological Analysis and Synthesis (NCEAS)
>> University of California Santa Barbara
>> Interested in ecological informatics? http://www.ecoinformatics.org
>> -------------------------------------------------------------------
>
>
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal 



-- 
UTS CRICOS Provider Code:  00099F
DISCLAIMER: This email message and any accompanying attachments may contain
confidential information.  If you are not the intended recipient, do not
read, use, disseminate, distribute or copy this message or attachments.  If
you have received this message in error, please notify the sender immediately
and delete this message. Any views expressed in this message are those of the
individual sender, except where the sender expressly, and with authority,
states them to be the views the University of Technology Sydney. Before
opening any attachments, please check them for viruses and defects.



More information about the Kepler-dev mailing list