Hi everyone,
> Do we have ideas for GSoC projects? Actually I have a couple ideas, in the scope of Batik: 1. Online SVG Rasterization Service Create an online service for SVG rasterization, as a valuable way to allow users to benefit from SVG while keeping up with the possibility of using raster images for software not natively supporting SVG (such as Internet Explorer, graphics authoring applications, office applications, etc.). Such service would/should allow: a. One-shot, manual/interactive image creation, possibly through a form with raster preview after applying settings (see related proposal by Ruud [1] [2] a while ago); b. On-demand, volume image creation through preset settings. This was potentially useful, for instance, as fallback for Web browsers without native SVG support (such as the Internet Explorer family of browsers, older mobile terminals or older browser versions), using markup like: <object type="image/svg+xml" data="myFile.svg"> <!-- oops, no SVG support, fallback to rasterized image --> <img type="image/png" src="http://xmlgraphics.apache.org/batik/rasterizer?url=http://myserver/myFolder/myFile.svg&targetW=320px&targetH=240&imgFormat=PNG"> </object> (Of course the above is a simplified example, without accounting with the need to encode the image's source URL and possibly other parameters supplied.) Also, there was a previous proposal on how to do this in an efficient way [3] based in the idea that a JVM for such service had to be reused between requests. As I'd hint towards ASF hosting such service (possibly using the distributed apache.org infrastructure), as a way to spread the word on Batik, SVG and ASF, it would naturally raise security challenges, as the servlet would need to connect to remote, untrusted sites in order to fetch the SVG file for rasterization. This would also be an opportunity to improve the project's security aspects, as well as benchmark ASF infrastructure itself. :-) 2. Batik-based SVG Viewer Create a high-quality (as usual!) Batik-based SVG Viewer applet. Although apparently trivial after taking a look at the project's demo [4], what was being proposed was a much more functional applet, with a context menu holding typical actions (zoom in/out, original view, view source, etc.). Also, possibly a reviewed implementation of browser's JavaScript<-->Batik's ECMAScript engine though Java<-->JavaScript communication [5] in order to implement the expected interfaces (GetSVGDocument [6], at the very least). The main goals here would be: a. A cross-(Web)browser SVG implementation which would help leveling look and feel of SVG while native implementations catch up (which is happening at a steady, though somehow slow, rhythm), and bring speed to most of them (Batik is much speedier than most Web browser native implementations I'm aware of); b. Create a (more) fully-featured component than JSVGCanvas already is, for integration in projects where one just wants a complete viewer component without the tailoring effort JSVGCanvas currently still requires. This idea was already proposed [7] (see item 5), though maybe with less detail. ;-) 3. Upgrade Regard [8] for SVG 1.1 Second Edition The Batik's "regression test suite does need a bit of love" (Cameron). I didn't report a tracking bug for this yet (again, this was also already proposed [7], see item 3) but the idea was to pick up the current state of the SVG 1.1 SE test suite [9] and integrate it into Batik. This would be a great boost in terms of the suite's usefulness because, AFAIK, the updated test suite uses an SVG font for all irrelevant (descriptive, version marking, etc.) text elements: this should help decreasing the number of false positives to a minimum. Currently the test infrastructure, still using the SVG 1.0 test suite, suffers a lot from the small differences in platform font rendering... :-| Hopefully, SVG 1.1 SE will not take very long to get to a recommendation state so I'd say that, by the time the work is ready and properly polished, only minor adjustments should be later required, when the final version of the specification is published. (I'm just guessing on the current status of the 1.1SE specification, I'm not sure if Cameron can provide some insight on that, specially if this project proposal sounds interesting.) I'm sure other interesting projects can be derived (or at least, inspired) by taking a look at the currently open issues for XML Graphics. ;-) > Are committers willing to be a mentor? I'd be willing to mentor any of the proposed projects and, depending on other projects' focus, I might be able to volunteer for those as well (that is, after knowing more about them). :-) Cheers, Helder [1] http://steltenpower.com/batik_form.html [2] http://old.nabble.com/on-improving-Batik%27s-usability-td7008728.html [3] http://old.nabble.com/running-batik-efficiently-in-a-web-server-environment-%28linux%29-td15684333.html [4] http://xmlgraphics.apache.org/batik/demo.html [5] https://jdk6.dev.java.net/plugin2/liveconnect/ [6] http://www.w3.org/TR/SVG/struct.html#InterfaceGetSVGDocument [7] http://old.nabble.com/Long%3A-Next-TODOs-and-debate-on-existing-ones-(was-"Re%3A-Welcome-to-Helder-Magalhães-as-a-committer")-td27675018.html [8] http://xmlgraphics.apache.org/batik/dev/test.html#regard [9] http://dev.w3.org/SVG/profiles/1.1F2/test/