The org.apache.batik.swing.svg provides Swing components that show SVG images. However, there is no bundled support for the Icon interface. Since the JGVTComponent extends the JComponent, it can't be used as a replacement for existing Icon implementations. It doesn't have to be as "clever" as the JGVTComponent and its extensions, but having painting / rendering transformation support is a must.
I agree, it probably would be handy to have such a class included in the distribution. Here is one I wrote a while ago (which isn't very clever), in case you have a need for one: http://mcc.id.au/2005/04/SVGIcon.java
Thanks for the implementation you have provided. Is it possible to augment this with resizability (as with the rendering transformation on the JGVTComponent)?
No doubt it is possible. For simple scaling, you can just pass in a different width/height to the constructor. For more complex transformations you could perhaps clone the document to add in a transform attribute on the root, or subclass the transcoder classes to do the same thing as the rendering transform on a JGVTComponent. Contributions are welcome. :)
I was thinking about simple scaling, but not wanting to create a different icon every time. SVG Salamander's implementation of SVGIcon has the setPreferredSize() method that scales the internal representation to the correct size. By the way, is the attached code synchronous or asynchronous (like JGVTComponent)?
It is synchronous. It just uses the transcoder to generate a BufferedImage the first time it needs to draw the icon, then uses that in subsequent draws.
Created attachment 18815 [details] Extension for the Batik icon with resizability and asynchronous load The attached class contains the implementation of Icon interface with asynchronous load (copied and modified from JGVTComponent) and resizability support (in setPreferredSize())
I just attached the extended version of the class that you gave earlier. It draws heavily from the asynchronous implementation of JGVTComponent (perhaps this code can be extracted into a common layer) + resizability support in setPreferredSize that schedules the rendering. In my application i've extended this icon class with another one that registers another GVT tree renderer listener and on completion calls a method on the containing component asking it to redraw the icon. This way, the icon is loaded asynchronously and the containing component is notified when it should redraw the icon. The only thing missing here for me - a static thread pool to dispatch the load requests on a limited number of threads to prevent out of memory exceptions.
Hi Kirill, Thanks for the contribution! It is useful as a patch in Bugzilla but it would be ideal if you could complete an Apache Individual Contributor License Agreement (ICLA) which would allow us to make this part of Batik. From a short review of the code, A couple of other things would need to be done for us to add it to the Batik code base: 1) It would have to be made compilable under JDK 1.3 (the current target for Batik). I see that it is using generics. I didn't see any really deep dependencies. 2) Something a little more elegant would need to be done with the rendering cache. I think it will be problematic to have the cache grow without bound. 3) Also a minor nit, remove the use of '*' in import statements.
Cameron, Where do i find that agreement to sign ICLA (hope it's OK and will not clash with my employer contract)? You're right about generics - i've wrote it in a 5.0 project, but the only thing there is for the image cache. I agree that it should be bound (LinkedHashMap would be soooo great here). I need to find / write some code to make the proper renderer thread pool. Hope it's not too complicated for 1.3. Last thing - about those * in imports. This is how i prefer them. I just *hate* two-three page-long import sections :) But that's just me. Feel free to hack at that code in the meantime until i find a reasonable and robust thread pool implementation. With any luck some other Apache project already has it...
Hi Kirill, (In reply to comment #9) > Where do i find that agreement to sign ICLA Sorry I ment to include the link: http://www.apache.org/licenses/ > (hope it's OK and will not clash with my employer contract)? This is exactly what the ICLA is ment to clarify, if you can actually contribute code to an Apache Project. > Last thing - about those * in imports. This is how i prefer them. > I just *hate* two-three page-long import sections :) But that's > just me. I just hate having no clue what a file is really depending on ;)
Created attachment 18819 [details] New implementation with support for thread pool
I just attached a new implementation that has support for thread pool. I've read through the linked license and it's too much pain for me to understand / consult at work / ... In addition, the thread pool implementation uses the new concurrent stuff from 5.0 (Executors and ExecutorService) - i just can't justify (for myself) to reinvent the wheel when my own project runs on 5.0. See comments on 40393 about a possibility to depend on Apache Excalibur and their thread pool - this is your decision if you want to provide support for this out of the box. It's just too much hassle for me to do something that already exists in two lines of code in JDK 5.0 by either implementing it myself / searching the web for ASF-compliant implementation / copy-pasting stuff from Excalibur. The current implementation (attached) just extends your own code with stuff from JGVTComponent + very simple support for resizing. Feel free to use it or any other approach if you decide to implement it in the next Batik version. I just don't feel very comfortable will that licensing / signing / lawyer-oriented language. Sorry.
(In reply to comment #12) > at work / ... In addition, the thread pool implementation uses the new > concurrent stuff from 5.0 (Executors and ExecutorService) - i just can't justify > (for myself) to reinvent the wheel when my own project runs on 5.0. Sounds reasonable (at least, to me). Marking as dependent on dropping Java 1.4 support (bug 46434) in order for this to be able to land without much more work in the future - whenever the project leaders decide Java 1.5 is the minimum version. Of course that, as already suggested, this can probably be reworked to support Java 1.4 (minimum version in trunk, currently)... > I just don't feel very comfortable will that > licensing / signing / lawyer-oriented language. Sorry. So this is it? A potentially great contribution getting lost in the bug tracker due to lack of a license agreement? I'd be pretty sad if this wasn't reverted. :-| Note that, in order for contributions to get integrated into the framework, the ICLA signing step [1] is necessary. This is basically only to assure no legal disputes will occur and that you really contribute things without anything in exchange (please correct me if I'm wrong!). Plain text [2] and PDF [3] versions are available. Marking the issue as "need info" to call for a follow up. Please re-consider contributing! :-) [1] http://www.apache.org/licenses/#clas [2] http://www.apache.org/licenses/icla.txt [3] http://www.apache.org/licenses/icla.pdf
(In reply to comment #13) > This is basically only to assure no legal > disputes will occur and that you really contribute things without anything in > exchange. I did try to find (but wasn't able to) a human-readable/simplified version of the Apache License - Creative Commons [1], for example, have such simplified summaries - just choose a license to see what I mean (at the bottom of each license there's a footnote pointing to the legal version). If someone is in possess of such link and/or knowledge, it would be great to share in order to, possibly, add a link and/or text portion to the license page [2] to make the legal understanding process smoother. :-) [1] http://creativecommons.org/licenses/ [2] http://xmlgraphics.apache.org/batik/license.html
(In reply to comment #14) > I did try to find (but wasn't able to) a human-readable/simplified version of > the Apache License Well, recently I stumbled across a human-readable summary [1] of the full license text which, although pretty introductory, should help. ;-) [1] http://www.codeproject.com/info/Licenses.aspx#ctl00_MC_LR_ctl08_N