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/
![http://xmlgraphics.apache.org/batik/rasterizer?url=http://myserver/myFolder/myFile.svg&targetW=320px&targetH=240&imgFormat=PNG"](http://xmlgraphics.apache.org/batik/rasterizer?url=http://myserver/myFolder/myFile.svg&targetW=320px&targetH=240&imgFormat=PNG"){kind=link}