Magnus and LDC wrote respectively
SVG graphics support was suggested on wikipedia-l. I like the idea; that's why I tried it for Nupedia once, but... :-( Proposal: [[svg:foobar]] is just plain-text editable, but displays as an image; A link to [[svg:foobar]] is displayed as an image as well. Optional, after saving an edit to [[svg:foobar]], an image (foobar.png) could be created via svg2png (never tried that, though). The image would then be displayed instead of the SVG, and "real" SVG display could be turned on in the user options (until most browsers support native SVG).
That's pretty much what I had in mind as well, but SVG isn't mature enough yet to think about. For now, people can upload the "source file" for a drawing in SVG, as well as uploading a PNG version, and just link to the PNG in the article.
I was just at:
http://bitflux.ch/developer/misc/xml_svg2image.html
http://cvs.php.net/co.php/pear/XML_svg2image/README.svg2image?r=HEAD
It sounds like Magnus proposal might be implementable but:
1. Integration may be tough or not yet reliably feasible 2. The required java/apache batik module may load the server
From my perspective it would be ideal if upon clicking the
associated png/jpeg image (or nearby link) one got either:
1. Directly editable SVG source text in the standard wiki edit box .... not terribly useful or user friendly
2. SVG source file (if available) loaded into SVG capable editor
Then upon save, an acknowledgement that the source had been modified and will be regenerated in the background at the server's earliest opportunity .... estimated to be x hours/days until standard usage patterns permit.
In the view of the current developers, would this type of initial capability be worth prototyping by a new developer attempting to get up to speed on the current software ... i.e. me?
Incidentally, this approach may turn out to be applicable to other advanced formats such as:
vrml adobe illustrator Autocad 3DS Max (an animation package) etc.
Clearly some of these other formats would be useful to specialists with access to high end tools when free source convertor utilities become available to appropriate display formats.
Issue 1. above might be best fixed by getting involved with the development and helping fix the remaining bugs that affect us specifically.
Issue 2. above might be addressable by using a separate low end internet accessible server as a "compile farm" via batch routines .... unless Bomis, the owner, the community or the impending board of the non profit are uncomfortable with relying on external resources for an operational capability. In this case, I can probably arrange for the donation and shipment/transport of an obsolete pentium system adequate for batch compilation to the central operational facility.
Obviously this would only be necessary if this approach is found to be feasible after prototyping and we decide to field an implementation.
Lee, regarding the immaturity of SVG. Do you think insufficient momentum has been achieved to assure that SVG will become widely fielded and reliaby?
Are there competing graphics standards that you feel might be more appropriate for immediate development effort if we do not wish to wait for wiki style collaboration on graphics source files?
Regards, Mike Irwin