Mailing List Archive

Magnus Manske wrote:
> 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).
>
> I didn't make this a feature request yet.

I'm not sure that SVGs are sufficiently user-friendly for it to make
sense to edit the source wiki-style, except perhaps for the simplest of
images (maybe for [[Square]] and [[Triangle]]...). To me, it makes more
sense to keep them in the [[image:]] space, with automagic conversion[1]
when we notice we're dealing with a *.svg. People can save the file,
edit it by hand or in an editor, and reupload; old revisions of uploaded
files are now kept and can be reverted easily if need be.

[1] Options for display could be:
* Inclusion of SVG code in single X(HT)ML document (for the future)
* Link to SVG as an <img> (Mozilla should handle this? I think)
* Link to SVG as <object> using plugin (ex, Adobe SVG viewer)
* Conversion to PNG
* ?

-- brion vibber (brion @ pobox.com)

On Sun, Aug 11, 2002 at 12:52:32PM -0800, Brion VIBBER wrote:
>
> I'm not sure that SVGs are sufficiently user-friendly for it to make
> sense to edit the source wiki-style, except perhaps for the simplest of
> images (maybe for [[Square]] and [[Triangle]]...).

I agree, editing that XML by hand is not going to be much used. There are
already applets out there that let you do some editing on an image. See, and
be amazed:

http://twiki.org:80/cgi-bin/view/Plugins/TWikiDrawPlugin

Unfortunately it's not using SVG although they seem to consider it. See:

http://twiki.org/cgi-bin/view/Plugins/TWikiDrawSvgPluginDev

It's a nice reminder of what is possible.

> To me, it makes more sense to keep them in the [[image:]] space, with
> automagic conversion[1] when we notice we're dealing with a *.svg.

For conversion to PNG I just tried the Batik tools. They are in the form of
Java jar files. At the moment I cannot get it to render text in images, but
it also complains about some missing fonts, so that could be my fault. For
the rest it seems to be working fine. In case you are interested and want to
try it yourself:

http://xml.apache.org/batik/

-- Jan Hidders

> 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.

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