Hi Werner:
I recently did a build of -DDEFAULT_ALL_DEVICES=ON and ran into some minor
build troubles with your pdf device driver (based on the haru library) which I
have now fixed (as of revision 10259). The worst of these was I was running
into header troubles and a showstopper build problem on Linux (using a newly
downloaded and built libharu-2.1.0). The culprit was the -DHPDF_SHARED
compile option for non windows builds. When that was removed, all was well.
You also may have to fiddle with -DHPDF_* options in cmake/modules/pdf.cmake
to get this device to build properly on Windows and Mac OS X with
libharu-2.1.0.
Once I had pdf.so built properly, I evaluated it in the build tree of the
installed examples using
SRC_EXAMPLES_DIR=${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/plplot-test.sh --verbose --front-end=c --device=pdf
where
CMAKE_CURRENT_SOURCE_DIR=/home/software/plplot_cvs/installcmake/share/plplot5.9.4/examples
for my particular case.
Running all 31 C examples for the pdf device that way showed no obvious
problems other than a segfault for C example 24.
Here is the full message from a standalone example 24 run with the pdf device:
softw...@raven> c/x24c -dev pdf -o test.pdf
ERROR: error_no=1050, detail_no=0
Segmentation fault
I don't have time/libharu expertise to look into this segfault any further,
but I assume libhpdf (from the libharu-2.1.0 package) is returning that
ERROR message, and the segfault occurs because that error is not handled
properly by the pdf device.
The pdf results from the above test looked fine using gv except for examples
10, 15, 17, 24, and 30. I think the issues with examples 10 (box and text
position), 15 (pattern fill spacing), and 17 (legend position) are all
related; my guess is these issues are due to the driver failing to properly
initialize all required PLplot coordinate system parameters. I have already
discussed the example 24 segfault above. Example 30 shows this driver does
not yet support transparent colours.
The special rendering test, examples/python/test_superscript_subscript.py
gives excellent looking results for the pdf device without any changes on my
part (the off-list report I got from a user about such problems for the "pdf
device" probably was referring to either the pdfqt or pdfcairo device.)
To summarize, it is probably still worthwhile to work on this driver since
the single libharu dependency is much simpler than the many different
pango/cairo or Qt4 libraries that our pdfcairo and pdfqt devices depend on.
I now have the pdf.so build problems straightened out on Linux (at least for
libharu-2.1.0) and most standard examples look good on that platform.
Finally, when you do have some spare time to continue work on this driver, I
hope these notes on the remaining small number of issues that I found will
be useful.
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
__________________________
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
