To produce an SVG form of the logo with -dev svg (which is the device which
plplot_logo.py has been explicitly tuned for) execute

make plplot_logo

in either the top-level of the build tree (configured with cmake
option -DBUILD_TEST=ON) or (after "make install" is run) in the build
tree of the installed examples configured by the new CMake-based build
system for those examples.  The above command actually runs the
equivalent of

./plplot_logo.py -dev svg -geometry 760x120 -o plplot_logo.svg

with proper dependencies and with plplot_logo.py run from the correct
directory with correct directory prefix on the output.  It also
generates plplot_logo.jpg (see below).  Both output files end up in
examples/python (if working in the top-level of the core build tree)
or python (if working in the top-level of the installed examples build
tree).

The plplot_logo.svg results look great on konqueror, but they are slow
to render.  The results also look good for display (for the default
compensation for text shifts) and take very little time to render.

Partially because of the file-bloating issue discussed on list (lots of
graphical objects outside device boundaries that are still included in the
file), the size of the file is 1.8M.  (Of course, another reason for this
large file size is there is incredible detail (many triangles) used to
represent the surface.

If I compress that file using

gzip -c <plplot_logo.svg >| plplot_logo.svgz

then the result is only 97 K (which is almost reasonable) and a factor of
almost 20 (!) in size over uncompressed.  Other results follow:

(1) The compressed result can still be quickly rendered with "display".

(2) The compressed result makes no difference to the slow konqueror rendering,
but that is konqueror's problem and not ours because of how quickly "display"
renders the result.

(3) Firefox 2 does not know what to do with the compressed result.  For
the uncompressed result it does not recognize the gradient.  These two
issues should be checked for firefox 3.

(4) scribus-ng quickly imports the compressed result with the same issues (no
clipping of results at the stated boundary of the device) as for the
uncompressed results.

(5) The compressed result is completely unrecognized by the w3c validator.
However, the uncompressed result (after a long upload) validates properly
at w3c.

Until the *.svgz compressed form becomes well-recognized (not least of
all by w3c), it is probably best to convert to jpeg to improve
rendering speed/reduce bandwidth compared to the uncompressed svg
file.  This convert step (also done with the above "make plplot_logo"
command) appears to get rid of everything outside the device
boundaries.

convert plplot_logo.svg plplot_logo.jpg

The result has a file size of 34K compared to the original jpeg logo
(www/img/header.jpg) put together by Werner (with external editor?) which
has a file size of 42K and which lacks a legend for the logo.  The "z axis"
label is shifted a bit by ImageMagick because of the librsvg-2.22 bug, and
until this bug is fixed I have put a default option into the original
plplot_logo.py file to compensate for this bug.  The result looks
essentially the same as the original logo (by design and fine-tuning of
plplot_logo.py), but the *.svgz form looks substantially better (if only it
would be more widely recognized).

The future prospects of reducing the uncompressed size of the *.svg result
to a reasonable value and the compressed size of the *.svgz result to a
miniscule value are good.  First, the solution of the file bloating issue
discussed on list (many graphical objects outside the device boundary
clipping limits are included unnecessarily in the file) should reduce the
file size by roughly a factor of three.  An even bigger reduction factor
for file size is expected when native gradients for file formats that
support them become supported by PLplot since that means the triangles used
to represent colour surfaces in PLplot can be made much larger without
compromising how good the result looks.

Alan W. Irwin 2008-10-19 (revised 2009-12-04)