Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> "UM" == Ulrich Mueller writes: JC> Unless, of course, a patch is added which makes «set term pdf» an JC> alias for «set term cairopdf». UM> Upstream has wisely named the terminal pdfcairo (not cairopdf). UM> Therefore, gnuplot's autocompletion will do its job, without any UM> additional patch. I should've remembered that when I replied. [SIGH] And it looks like pdfcairo alread is sufficiently compatible with pdf. So no objections here to the change you already pushed. ☺ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Wed, 23 Feb 2011, James Cloos wrote: > Gnuplot’s cairopdf terminal generates vector output. One might argue > that it is not optimal, but only because it uses line segments > rather than cubic curves to approximate graphs. (Ie, it uses cairo’s > lineto rather than curveto functions.) > But so do gnuplot’s native terminals (I tested postscript and svg.) > That is just how gnuplot draws. Thank you for this nice analysis. > I’d still keep the pdf USE flag with its current meaning; users may > have existing gnuplot scripts which use gnuplot’s pdf terminal > and/or apps which generate such scripts. I don't think that keeping media-libs/pdflib in the tree is realistic. There is no Gentoo maintainer and it has open security issues. Besides, version 7 is discontinued, and version 8 is available only as a binary (static) library under commercial licensing. Of course, such decisions are sometimes painful. But will they be less painful if we postpone them by another year or two? > Unless, of course, a patch is added which makes «set term pdf» an > alias for «set term cairopdf». Upstream has wisely named the terminal pdfcairo (not cairopdf). Therefore, gnuplot's autocompletion will do its job, without any additional patch. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> "FR" == Francesco R writes: FR> Last time (many moons ago) I've checked cairo did not generated pdf FR> it did generated raster images and wrapped them in a thin pdf layer. FR> pdflib is generating vector pdf which is a different thing. Cairo will fall back to an image for anything which cannot be described by whichever output driver one uses. Transparency will cause that when generating PostScript, for instance, because PostScript does not support transparency. But there are few—if any—ops which cairo supports which are not also supported by pdf. Gnuplot’s cairopdf terminal generates vector output. One might argue that it is not optimal, but only because it uses line segments rather than cubic curves to approximate graphs. (Ie, it uses cairo’s lineto rather than curveto functions.) But so do gnuplot’s native terminals (I tested postscript and svg.) That is just how gnuplot draws. I’d still keep the pdf USE flag with its current meaning; users may have existing gnuplot scripts which use gnuplot’s pdf terminal and/or apps which generate such scripts. Unless, of course, a patch is added which makes «set term pdf» an alias for «set term cairopdf». -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 15:18:18 Ulrich Mueller wrote: > > On Tue, 22 Feb 2011, Matt Turner wrote: > > Then please say that to begin with instead of something snooty like > > "You should check again." > > Sorry, but I don't see what would be snooty about it. That was not at > all my intention, and I apologise if it came across like that. *shrug* that's how i read it as well if cairo produces proper output now instead of faking it, i guess that qualifies as a suitable replacement for pdflib and we can chuck the pos. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Matt Turner wrote: > Then please say that to begin with instead of something snooty like > "You should check again." Sorry, but I don't see what would be snooty about it. That was not at all my intention, and I apologise if it came across like that. Francesco's statement was something like "many months ago I've checked cairo". I don't know what his exact usage case is (because he didn't say it). I only know that I don't have problems with my own usage case, which may be very different from Francesco's. So how can I learn if his problem persists, other than asking him to repeat the tests with a recent cairo version? Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tue, Feb 22, 2011 at 7:13 PM, Ulrich Mueller wrote: >> On Tue, 22 Feb 2011, Tomáš Chvátal wrote: > >> Dne 22.2.2011 19:20, Mike Frysinger napsal(a): > Last time (many moons ago) I've checked cairo did not generated > pdf it did generated raster images and wrapped them in a thin pdf > layer. pdflib is generating vector pdf which is a different > thing. You should check again. >>> >>> are you saying that because you know cairo has fixed itself, or >>> because you dont know the answer yourself ? > > I know that for my usage cases, gnuplot's pdfcairo terminal produces > proper PDF output. Then please say that to begin with instead of something snooty like "You should check again."
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
Tomáš Chvátal dixit (2011-02-22, 19:39): > >>> On Tue, 22 Feb 2011, Francesco R wrote: > > Build gnuplot with USE="cairo" and you can get PDF output with the > > "pdfcairo" terminal. > >>> > >>> Last time (many moons ago) I've checked cairo did not generated pdf > >>> it did generated raster images and wrapped them in a thin pdf layer. > >>> pdflib is generating vector pdf which is a different thing. > >> > >> You should check again. > > > > are you saying that because you know cairo has fixed itself, or because you > > dont know the answer yourself ? > > -mike > To my best knowledge cairo can do proper pdf files. > > Courtesy of 12 lines of python, see the attachment, both vector curves > and normal text in one fancy pdf file. I don't see any curves (in any pdf viewer), only some ZOMG_TEXT. I always thought Python was suspicious :). -- [a] pgpbeRCIEtHeg.pgp Description: PGP signature
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Tomáš Chvátal wrote: > Dne 22.2.2011 19:20, Mike Frysinger napsal(a): Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing. >>> >>> You should check again. >> >> are you saying that because you know cairo has fixed itself, or >> because you dont know the answer yourself ? I know that for my usage cases, gnuplot's pdfcairo terminal produces proper PDF output. > To my best knowledge cairo can do proper pdf files. AFAIK, even programs like Inkscape use cairo for export of PostScript and PDF. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
Dne 22.2.2011 19:20, Mike Frysinger napsal(a): > On Tuesday, February 22, 2011 12:54:11 Ulrich Mueller wrote: >>> On Tue, 22 Feb 2011, Francesco R wrote: > Build gnuplot with USE="cairo" and you can get PDF output with the > "pdfcairo" terminal. >>> >>> Last time (many moons ago) I've checked cairo did not generated pdf >>> it did generated raster images and wrapped them in a thin pdf layer. >>> pdflib is generating vector pdf which is a different thing. >> >> You should check again. > > are you saying that because you know cairo has fixed itself, or because you > dont know the answer yourself ? > -mike To my best knowledge cairo can do proper pdf files. Courtesy of 12 lines of python, see the attachment, both vector curves and normal text in one fancy pdf file. Tom output.pdf Description: Adobe PDF document signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 12:54:11 Ulrich Mueller wrote: > > On Tue, 22 Feb 2011, Francesco R wrote: > >>> Build gnuplot with USE="cairo" and you can get PDF output with the > >>> "pdfcairo" terminal. > > > > Last time (many moons ago) I've checked cairo did not generated pdf > > it did generated raster images and wrapped them in a thin pdf layer. > > pdflib is generating vector pdf which is a different thing. > > You should check again. are you saying that because you know cairo has fixed itself, or because you dont know the answer yourself ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Francesco R wrote: >>> Build gnuplot with USE="cairo" and you can get PDF output with the >>> "pdfcairo" terminal. > Last time (many moons ago) I've checked cairo did not generated pdf > it did generated raster images and wrapped them in a thin pdf layer. > pdflib is generating vector pdf which is a different thing. You should check again. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
2011/2/22 Rich Freeman : > On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote: >>> On Tue, 22 Feb 2011, Mike Frysinger wrote: >>> that might disallow it for binaries, but it doesnt disallow it from >>> being used in ebuilds. same situation as binary kernel drivers -- >>> make it the end user's problem. >> >> Why should we impose such trouble on our users, when there's a (IMHO >> superior) replacement? Build gnuplot with USE="cairo" and you can get >> PDF output with the "pdfcairo" terminal. Even with proper utf-8 >> support, which was always broken with pdflib. > > +1 to both - if a free alternative works then we should always prefer > it. However, at worst linking license issues should just force us to > set RESTRICT="bindist" or the like (and mirror as well if we can't > distribute the source). As long as users don't redistribute software > they don't need to worry about licenses if the person sending it to > them had the license to distribute it in the first place. > > Rich > Last time (many moons ago) I've checked cairo did not generated pdf it did generated raster images and wrapped them in a thin pdf layer. pdflib is generating vector pdf which is a different thing.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote: >> On Tue, 22 Feb 2011, Mike Frysinger wrote: >> that might disallow it for binaries, but it doesnt disallow it from >> being used in ebuilds. same situation as binary kernel drivers -- >> make it the end user's problem. > > Why should we impose such trouble on our users, when there's a (IMHO > superior) replacement? Build gnuplot with USE="cairo" and you can get > PDF output with the "pdfcairo" terminal. Even with proper utf-8 > support, which was always broken with pdflib. +1 to both - if a free alternative works then we should always prefer it. However, at worst linking license issues should just force us to set RESTRICT="bindist" or the like (and mirror as well if we can't distribute the source). As long as users don't redistribute software they don't need to worry about licenses if the person sending it to them had the license to distribute it in the first place. Rich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Tue, 22 Feb 2011, Mike Frysinger wrote: >> sci-visualization/gnuplot[pdf] is currently linking against pdflib. >> I'm going to remove that dependency, because in my understanding, >> clause 2.1 of the PDFLite license does not allow such linking. (It >> allows it for programs under an OSI approved license. However, the >> gnuplot license is free, but not OSI approved.) > that might disallow it for binaries, but it doesnt disallow it from > being used in ebuilds. same situation as binary kernel drivers -- > make it the end user's problem. Why should we impose such trouble on our users, when there's a (IMHO superior) replacement? Build gnuplot with USE="cairo" and you can get PDF output with the "pdfcairo" terminal. Even with proper utf-8 support, which was always broken with pdflib. Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
> On Mon, 21 Feb 2011, Jeremy Olexa wrote: > The bugs are stacking up[1] and upstream only offers a paid version of > pdflib-8[2]. It is my understanding that there is no way for us to > package future versions and the bundled libs are vulnerable[3]. > So, should it be removed? For more info, see the tracker bug for its > removal[1], there are a number of rdeps that will require fixing[4]. sci-visualization/gnuplot[pdf] is currently linking against pdflib. I'm going to remove that dependency, because in my understanding, clause 2.1 of the PDFLite license does not allow such linking. (It allows it for programs under an OSI approved license. However, the gnuplot license is free, but not OSI approved.) Ulrich
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 02:29:06 Ulrich Mueller wrote: > > On Mon, 21 Feb 2011, Jeremy Olexa wrote: > > The bugs are stacking up[1] and upstream only offers a paid version of > > pdflib-8[2]. It is my understanding that there is no way for us to > > package future versions and the bundled libs are vulnerable[3]. > > > > So, should it be removed? For more info, see the tracker bug for its > > removal[1], there are a number of rdeps that will require fixing[4]. > > sci-visualization/gnuplot[pdf] is currently linking against pdflib. > I'm going to remove that dependency, because in my understanding, > clause 2.1 of the PDFLite license does not allow such linking. > (It allows it for programs under an OSI approved license. However, the > gnuplot license is free, but not OSI approved.) that might disallow it for binaries, but it doesnt disallow it from being used in ebuilds. same situation as binary kernel drivers -- make it the end user's problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
On Tuesday, February 22, 2011 00:32:52 Jeremy Olexa wrote: > The bugs are stacking up[1] and upstream only offers a paid version of > pdflib-8[2]. It is my understanding that there is no way for us to > package future versions and the bundled libs are vulnerable[3]. > > So, should it be removed? For more info, see the tracker bug for its > removal[1], there are a number of rdeps that will require fixing[4]. is there a suitable replacement functionality wise ? i'm aware of PHP based PDF generators (which often work great), but there doesnt seem to be any replacement for this package atm ? -mike signature.asc Description: This is a digitally signed message part.
