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)

The Status of the Python Examples

For details of how we build PLplot access from Python please consult
../../bindings/python/README.pythonbuild.  The principal module is
plplot.py. This make all the common PLplot API available to python in a
user-friendly way.  plplot.py wraps the swig-generated plplotc.py which in
turn wraps the _plplotc extension module (built with the aid of swig). The
extension module, plplot_widget contains support for loading Plframe
from python.  This functionality is demonstrated with pytkdemo which
supplies GUI access to python standard examples 0 through 18 (except
for 14, 15, and 17).

To try out the x??.py examples without a widget simply run pythondemos.py
to run all of them (0-33) in numerical order (except for 14, 17, and 31 which
are standalone, and 32 which does not exist). Alternatively run them
one at at time by executing x??.

These pytkdemo, pythondemos.py, and x?? tests should be run in the python
subdirectory of the examples directory of the build tree (after python
prequisites have been built) or the equivalent directory for the installed
examples build.

We have implemented a number of simple python standalone scripts to test for
rendering issues with our PLplot device drivers.

N.B. these tests should not be propagated to other languages.  python is
ideal for rapid development and evaluation.  Given this, it is expected
these tests will change substantially over time and more tests will be
added. Thus, propagating those expected changes to other languages is
largely pointless.

N.B. the SVG test results for "firefox", "konqueror", and "display" reported
below at this time of writing (2009-08-12) are for Debian Lenny where
firefox is iceweasel Version 2.0.0.14-2, konqueror is Version
4:3.5.9.dfsg.1-6, and by default display (Version 7:6.3.7.9.dfsg2-1~lenny1)
uses the rsvg2 GNOME library to render svg files. Your SVG viewing results
will differ for other versions of firefox, konqueror, and display.  They
will also differ for other SVG-aware applications because SVG viewing and
rendering within Linux is still a bit problematic, even though Linux is
probably in better SVG shape than other platforms.

* test_circle.py (only useful for testing unicode-aware devices) renders a
series of "LARGE CIRCLE" and "BOX DRAWINGS LIGHT DIAGONAL CROSS" unicode
characters from (very) large sizes to small sizes to check there is no
vertical drift in the alignment of the characters, and also to check that
very large versions of characters are rendered correctly.  -dev xcairo
results have good alignment and good character rendering. -dev svg results
validate correctly at http://validator.w3.org/,
have good alignment and good character rendering according to the
ImageMagick "display" application and firefox, but those same results cannot
be rendered by konqueror because it cannot find the appropriate system
fonts. -dev qtwidget results have good alignment, but the large character
rendering is not reliable ("squashed" left edge of "LARGE CIRCLE" for the
three largest sizes, but no squashing at the smaller sizes).

* testh.py renders a vertical line at the left edge of the window, a
horizontal line marking the center of the vertical line, and a centred
string of 7 "H" characters superimposed on top of the vertical line so the
horizontal bar of the "H" is very close to the vertical line and parallel
with it.  All drivers we have tested generate correct interactive or file
results for this figure.  Also, the -dev svg output file validates at
http://validator.w3.org/, and I get good rendering results for both firefox
and konqueror for that output file.  However, those output file results are
_not_ rendered correctly by the GNOME library, librsvg2, which is used in a
number of applications (e.g., all GNOME text rendering applications which
are svg aware such as eog and (depending on how ImageMagick is compiled) the
ImageMagick "display" application).  See
http://bugzilla.gnome.org/show_bug.cgi?id=525023 for more details.

* test_superscript_subscript.py renders a series of nested superscripts and
subscripts for single numbers from 0 to 9 and also tries some simple
superscripts and subscripts for Greek letters and ordinary (Roman) letters.
Devices that use our traditional Hershey fonts (e.g., -dev xwin) have
good results for this example, but there is work to do to get similar
good results for our more modern devices that use other means of
superscripting and subscripting.

The one current exception to this is -dev svg where the resulting output
file validates at http://validator.w3.org/, and the dy attribute of the
nested span tags is written correctly. Furthermore, I get good rendering
results for this output file using the ImageMagick "display" application.
However, in this case the vertical positioning after the Greek superscript
or subscript letters in the output svg file is not rendered correctly by
mozilla and konqueror.  On the other hand, those applications have no
trouble rendering the text after superscript/subscript Roman (ordinary)
letters.  It appears those applications are having trouble dealing with a
nested series of span tags when there is a font change (e.g., for Greek
letters) in the middle of the series.  The results for the pdf, cairo, and
qt devices for this example are poor (e.g., do not agree with the good
-dev xwin results), but it is planned to deal with those issues soon.