Hi,
I wrote this list of ideas recently[12], and thought I should re-post
here those items which are SVG related (which is a majority of the
full list.)
Things I'd like to program if only I had the time. Please let me know
[1] if you're aware of already existing projects which come close to
any one of these. Also let me know if you're interested in any of
these. Of course, if you'd even like to sponsor one of these projects
then I could probably take the time for it.
+ An X3D to SVG converter. It would take a 3D mesh and camera
settings, apply projection, do back-face culling, sort polygons by z-
order, dividing intersecting polygons, apply comic shading. Gouraud
shading would also be possible, using gradients, but using only a
finite number of shades has its advantages. We can then combine
adjacent polygons of the same color and shade, and replace the
outlines' faces with cubic bezier curves based on normals. This
allows us to render smooth 2D representations from low polygon models.
+ A Greasemonkey script which adds SVG font support to Firefox. For
the actual outlining of text Jason Gallicchio's SVGFontKit[2] could
be used. The important part is that the script should add
DOMMutationEvents[3] which update the text outlines, so the font
script works nicely together with most other scripts. For example, it
should work well in comination with FakeSmile[4], which also is a
Greasemonkey script which fixes lacking web standards support in
Firefox, so making them incopatible would drastically limit the
usefulness of the project.
+ An XHTML deploy script, which transforms XHTML documents to
something even the Microsoft Internet Explorer can interpret
correctly. There are two options. It can be transformed to correct
HTML, or, if XML features like foreign namespaces are actually
needed, to XHTML following the HTML compatibility guidelines[5] with
PHP code for choosing the MIME type depending on the Accept field of
the HTTP request header. So the options are HTML or PHP. In a PHP
document the processing instructions Internet Explorer needs so it
can handle certain foreign namespaces would be added automatically by
the script. It could also support XHTML+SMIL[6] by making it
compatible with HTML+TIME 2 for Internet Explorer, and linking in the
FakeSmile[4] script for other browsers. Conditional comments[7] make
such a thing possible. For deploying inline SVG for Internet Explorer
there are several options. ASV, conversion to an alternative VML
version, rendering to a raster image format...
The basic idea is that the author should write plain XHTML, and the
deploy script works around many of the browser specific problems
which one normally needs to consider. Web design is fun again.
Without much reading about browser specific issues one can use things
which normally wouldn't simply work, like SVG, and object tags for
images. They would still work better in some browsers than in others,
but when the workarounds can be added automatically, people would
start using these technologies more widely, which would also increase
pressure on browser vendors to improve their standards support.
That's the idea. Of course it wouldn't really work this way. But it
could be useful for me, and maybe a few other people.
+ An SVG editor Greasemonkey script. I've already got some ideas for
the interface. Important features would be optional rounding of
values to integer numbers, to create small files; and support for all
SVG path segment types, as is already implemented in my current FeSVG
path data editor[8], plus some additional path segments, which can be
transformed to SVG's standard path segments. A neat feature would be
z-scrolling: press the Z key, then move the mouse vertically to put
more or fewer elements into a group element at the top, which ignores
pointer events and is transparent, so you can easily edit elements
which were partially hidden. Most commands would be invoked by
keyboard events, not by buttons as those I use in my current FeSVG
path data editor.
+ SVG font diacritical combiner. One feature I'm missing in the
current SVG fonts specification is good support for combining
diacritical marks. The concept for how this should work comes from
FontForge[9].
Glyphs could contain information on where to position diacriticals,
stored in elements of a foreign namespace. We would have to define
multiple anchor points. One anchor point where diacriticals would be
added above the glyph (diaeresis, tilde, grave accent, etc.), one
anchor point for diacriticals below (cedilla, comma accent). It
should be possible to use an arbitrary number of anchor points, to
not limit the set of scripts for which this would work. Then we need
combining diacritical elements, which are syntactically similar to
glyph elements, but they don't have a progression width. When added
to a base glyph a diacritical is positioned relative to one of the
anchor points, and it
