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
>    default).

Alan,

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!

Andrew

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to