[gentoo-dev] Pending removal(?) of media-libs/pdflib

[gentoo-dev] Pending removal(?) of media-libs/pdflib

[Jeremy Olexa]

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].

[1]: https://bugs.gentoo.org/355971
[2]: http://www.pdflib.com/download/free-software/pdflib-lite-7/
[3]: https://bugs.gentoo.org/253263
[4]: http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/pdflib

Thanks,
-Jeremy

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 618 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Ulrich Mueller]

>>>>> 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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 999 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Ulrich Mueller]

>>>>> 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

[Rich Freeman]

On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller <ulm@gentoo.org> 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

[Francesco R]

2011/2/22 Rich Freeman <rich0@gentoo.org>:
> On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller <ulm@gentoo.org> 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

[Ulrich Mueller]

>>>>> 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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 582 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Tomáš Chvátal]

[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]

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

[-- Attachment #1.2: output.pdf --]
[-- Type: application/pdf, Size: 11017 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Ulrich Mueller]

>>>>> 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

[Antoni Grzymala]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

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]

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Matt Turner]

On Tue, Feb 22, 2011 at 7:13 PM, Ulrich Mueller <ulm@gentoo.org> 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

[Ulrich Mueller]

>>>>> 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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 554 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[James Cloos]

>>>>> "FR" == Francesco R <vivo75@gmail.com> 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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

[Ulrich Mueller]

>>>>> 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

[James Cloos]

>>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> 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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6