On Friday 11 Oct 2013 18:26:59 Alan W. Irwin wrote:
> On 2010-07-29 07:56+0100 Andrew Ross wrote:
> > Alan,
> > I agree it is worth maintaining for a lightweight pdf solution. I'll look
> > into packaging libharu for Debian.
> > Andrew
> > On Tue, Jul 27, 2010 at 04:21:03PM -0700, Alan Irwin wrote:
> >> [...]Andrew, would you be interested in packaging up libharu (with my
> >> changes) for Debian?
> Hi Andrew:
> To resurrect this extremely old thread, the situation now is there
> exist libhpdf (a.k.a., libharu) Debian packages for version 2.2.1 that
> have been packaged by someone else, and if our pdf device is linked to
> that version, all is well for every example except for example 24
> which craps out with a segfault. From my experience with 2.1.0, and
> the fact that the two-line patch also applies cleanly to 2.2.1, I am
> pretty sure that the Debian packager simply needs to apply the patch I
> have given at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726069.
> However, I could not test that patch on the Debian version of the
> library because for some reason "apt-src build" builds the debs
> without obvious issues, but when those debs are installed, the
> resulting libhpdf library does not define needed symbols as revealed
> by comparing
> objdump --dynamic-syms /usr/lib/libhpdf.so
> results for the standard Debian package and the one built by apt-src.
> Would you be willing to take a further look at the Debian package to
> see if it builds with apt-src on Debian unstable (patched with my
> patch or not) with all the required symbols as detected by objdump?
> Furthermore, if you confirm the symbol problem exists, would you look
> to see if there is some simple packaging fix that needs to be made for
> the libhpdf source package?
> I assume the differences between wheezy and unstable are pretty
> small at the moment so if you can get that Debian apt-src build
> to install a libhpdf library with needed symbols, then I
> bet your solution would work for me as well.
> Here is some additional news about the pdf device.
> * I have sorted out a hpdf subdirectory issue for the location of
> hpdf.h (revision 12589).
> * I have enabled this device by default (revision 12590) since it
> works for me for all examples in contexts (build_projects on both
> Linux and Wine) where the above patch is applied to the libhpdf
> build. And I am pretty sure once the Debian package for libhpdf can
> be built properly, that we will be able to prove the same thing for
> the (patched) Debian packaged version of libhpdf.
> * There are some on-going issues with this device that are revealed by
> the standard example results I looked at in detail today. Example
> 10 shows an offset of the box that is probably due to some bug in
> the way that the pdf device is set up in drivers/pdf.c; examples 23,
> 24, and 26 show large issues with the selection of unicode glyphs
> available for libhpdf (indeed only the limited Type 1 glyphs seem to
> be available); and examples 4, 26, 30, and 33 illustrate that
> libhpdf does not (yet) support an alpha (transparency) channel.
> Nevertheless, despite these drawbacks, -dev pdf provides a
> lightweight pdf solution that will be satisfactory for many plotting
> needs (which is another reason why I have now enabled this device by
That's interesting. I'd somewhat forgotten about this. I'll have a look at the
Debian specific issues and see if I can get the pdf driver packaged up.
By the way - and I've probably mentioned this before - I use pbuilder to
building the Debian unstable packages on a Ubuntu stable machine. You can do
the same with Debian stable. This works well and is much lighter weight than
installing a virtual machine. Advantages are that you keep a stable platform,
but can test with cutting edge. For packaging it has the added advantage that
you start with a clean base system each time which makes checking build and
runtime dependencies much easier. You might be interested in this for plplot
or for other projects - time permitting of course!