I would like to permanently disable the gd and gcw device drivers as well
as the gnome2 and pygcw bindings associated with the gcw device driver for
this forthcoming release.
Here is my justification for this proposed change.
* gd and gcw are unmaintained.
* Unicode text for the gd and gcw device drivers is rendered with plfreetype
which is not only unmaintained, but which also has a number of its own
issues which affect these devices such as
+ incorrect/inconsistent text offsets
+ font selection by file name which means it is inconvenient to specify
fonts, and unlike the cairo and qt device drivers, there is no automatic
method of picking the right font from the collection of fonts installed
on a users system to give the best possible rendering of each glyph.
+ incorrect simple left-to-right text layout of language scripts (Arabic,
Hebrew, plus many far eastern languages) which have complex text layout
(not only in the horizontal direction, but sometimes in the vertical
direction as well).
* gd and gcw provide functionality which is (mostly) superseded by other
device drivers.
+ -dev gcw provides an interactive device which is virtually identical to
-dev xcairo (which makes sense since libpango/libcairo are the heart of
GNOME rendering).
+ The gnome2 bindings (which allow access to the PLplot API for GNOME GUI
applications) provides functionality similar to what is available from
-dev xcairo and -dev extcairo to draw into an externally supplied
XDrawable or Cairo context (see examples/c/README.cairo). Of course,
-dev extcairo is currently broken, but I assume that is going to be
fixed since our cairo device driver tends to be well maintained.
+ The gd device driver provides -dev png (now superseded by -dev pngcairo
and -dev pngqt), and -dev jpeg (now superseded by -dev jpgqt).
- The gd device also provides -dev gif which is not superseded by
anything. On the other hand the GIF format has some limitations
(notably only 256 colours), and PNG format is a good replacement for it.
Furthermore, users who absolutely feel they need GIF format even when
the better PNG format is available can always use the ImageMagick
"convert" application to downgrade our PNG results to GIF. Thus, I feel
there is little downside to removing our (lame) support of the GIF
format altogether.
- Nothing currently supersedes the pygcw bindings which provide python
GTK+ access to the PLplot API. On the other hand, those bindings were
broken for a long time and nobody complained. Also, I suspect it would
be straightforward to adapt either the XDrawable xcairo or extcairo
approaches to work in the python case as well.
The "permanent" disabling step I am proposing is simply to edit our build
system (i.e., comment out the gd- and gcw-related lines in
cmake/modules/drivers-init.cmake so that the gd and gcw device drivers are
completely ignored. (Disabling gcw this way automatically disables the
gnome2 and pygcw bindings.) The result would be nobody could use these
device drivers and associated bindings (unless they knew enough to uncomment
the lines in cmake/modules/drivers-init.cmake). Of course, this permanent
disabling step would be mentioned/justified in the release notes.
Before taking the fairly drastic step of permanently disabling these devices
(and associated bindings) I want to check with others here for your opinion
of this proposed change. If anybody here feels strongly about keeping these
devices around for the next release, I would certainly be willing to go
along with the compromise of simply turning OFF these devices by default
(which gives the users the choice of turning them ON if they really need
them). However, I feel the above long list of woes is probably
justification for more drastic action.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
