Re: [Swftools-common] external libraries carried in source

[Matthias Kramm]

On Tue, Jun 10, 2008 at 12:08:15PM +0200, Patrice Dumas <address@hidden> wrote:
> There are some external libraries in swftools source, at least gocr,
> libart_lgpl and lame.
> 
> There also seems to be bladeenc, though it doesn't seems to be used by
> anything.

This is only in CVS. The source archives don't contain bladeenc anymore.
(Nor do they contain lame, for that matter)

> I see 2 reasons why they could be here, to help the user avoiding to have to
> install them and because they are patched, is there another reason?

Both correct.

> Are the other (gocr, libart_lgpl and lame) patched?

libart is patched quite heavily. (in particular, the intersection code-
the changes will be fed upstream soon)

gocr and lame contain only small cosmetic fixes (some removed warning
messages etc.).

> Did I miss other in-source libraries?

lib/action contains Ming's Action Compiler, though I don't think that
exists as explicit library on any distribution.

> I have checked that swftools build fine against the system libart_lgpl
> but I haven't tested it (it is what is done in debian packaging too, so
> I guess that it has received testing).

It may work well for older versions, but for newer versions, you
definitely need the patched libart.

> Could it be possible to have the possibility to compile against system
> libraries? (I can do some autoconf/Makefile.in related work to have it
> happen, but I don't want to force a design).

It's possible to link against the system lame. It's not possible to
link against gocr or libart.

> Using system libs
> (especially when they are shared) is practical for integration of
> software, since the correction of a bug in the library is automatically
> (in cas of shared lib) or easily (in case of static lib) propagated.

Yes- but new bugs in libraries are propagated as well.
This happens more often than you would think- bugs in specific freetype
versions are quite often the cause for abnormal behaviour of swftools
programs.

> Also I think that it would be better to link against poppler instead of
> xpdf. 

Poppler is a nice project. I would like to merge my xpdf tree with
theirs- but it's a large effort, and also the link between pdf2swf
and xpdf is very fragile when it comes to changes in the xpdf sources,
so this might cause more problems than it would do good.

The changes are also quite large- take a look at
lib/pdf/xpdf-changes.patch for details.

> If there are things from xpdf that are needed and are not in
> poppler, it may be possible to try to have them i poppler

If the changes are to be merged, I'd rather merge them into xpdf
upstream at some point in time.
I have some customers which use bleeding-edge xpdf versions purchased
from the xpdf maintainer, which are not yet contained in any poppler
versions.

Greetings

Matthias