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