"Fossies" - the Fresh Open Source Software Archive

Member "plplot-5.15.0/examples/python/README.logo" (1 Jun 2019, 4090 Bytes) of package /linux/misc/plplot-5.15.0.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 To produce an SVG form of the logo with -dev svg (which is the device which
    2 plplot_logo.py has been explicitly tuned for) execute
    3 
    4 make plplot_logo
    5 
    6 in either the top-level of the build tree (configured with cmake
    7 option -DBUILD_TEST=ON) or (after "make install" is run) in the build
    8 tree of the installed examples configured by the new CMake-based build
    9 system for those examples.  The above command actually runs the
   10 equivalent of
   11 
   12 ./plplot_logo.py -dev svg -geometry 760x120 -o plplot_logo.svg
   13 
   14 with proper dependencies and with plplot_logo.py run from the correct
   15 directory with correct directory prefix on the output.  It also
   16 generates plplot_logo.jpg (see below).  Both output files end up in
   17 examples/python (if working in the top-level of the core build tree)
   18 or python (if working in the top-level of the installed examples build
   19 tree).
   20 
   21 The plplot_logo.svg results look great on konqueror, but they are slow
   22 to render.  The results also look good for display (for the default
   23 compensation for text shifts) and take very little time to render.
   24 
   25 Partially because of the file-bloating issue discussed on list (lots of
   26 graphical objects outside device boundaries that are still included in the
   27 file), the size of the file is 1.8M.  (Of course, another reason for this
   28 large file size is there is incredible detail (many triangles) used to
   29 represent the surface.
   30 
   31 If I compress that file using
   32 
   33 gzip -c <plplot_logo.svg >| plplot_logo.svgz
   34 
   35 then the result is only 97 K (which is almost reasonable) and a factor of
   36 almost 20 (!) in size over uncompressed.  Other results follow:
   37 
   38 (1) The compressed result can still be quickly rendered with "display".
   39 
   40 (2) The compressed result makes no difference to the slow konqueror rendering,
   41 but that is konqueror's problem and not ours because of how quickly "display"
   42 renders the result.
   43 
   44 (3) Firefox 2 does not know what to do with the compressed result.  For
   45 the uncompressed result it does not recognize the gradient.  These two
   46 issues should be checked for firefox 3.
   47 
   48 (4) scribus-ng quickly imports the compressed result with the same issues (no
   49 clipping of results at the stated boundary of the device) as for the
   50 uncompressed results.
   51 
   52 (5) The compressed result is completely unrecognized by the w3c validator.
   53 However, the uncompressed result (after a long upload) validates properly
   54 at w3c.
   55 
   56 Until the *.svgz compressed form becomes well-recognized (not least of
   57 all by w3c), it is probably best to convert to jpeg to improve
   58 rendering speed/reduce bandwidth compared to the uncompressed svg
   59 file.  This convert step (also done with the above "make plplot_logo"
   60 command) appears to get rid of everything outside the device
   61 boundaries.
   62 
   63 convert plplot_logo.svg plplot_logo.jpg
   64 
   65 The result has a file size of 34K compared to the original jpeg logo
   66 (www/img/header.jpg) put together by Werner (with external editor?) which
   67 has a file size of 42K and which lacks a legend for the logo.  The "z axis"
   68 label is shifted a bit by ImageMagick because of the librsvg-2.22 bug, and
   69 until this bug is fixed I have put a default option into the original
   70 plplot_logo.py file to compensate for this bug.  The result looks
   71 essentially the same as the original logo (by design and fine-tuning of
   72 plplot_logo.py), but the *.svgz form looks substantially better (if only it
   73 would be more widely recognized).
   74 
   75 The future prospects of reducing the uncompressed size of the *.svg result
   76 to a reasonable value and the compressed size of the *.svgz result to a
   77 miniscule value are good.  First, the solution of the file bloating issue
   78 discussed on list (many graphical objects outside the device boundary
   79 clipping limits are included unnecessarily in the file) should reduce the
   80 file size by roughly a factor of three.  An even bigger reduction factor
   81 for file size is expected when native gradients for file formats that
   82 support them become supported by PLplot since that means the triangles used
   83 to represent colour surfaces in PLplot can be made much larger without
   84 compromising how good the result looks.
   85 
   86 Alan W. Irwin 2008-10-19 (revised 2009-12-04)