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

[Patrice Dumas]

On Tue, Jun 10, 2008 at 12:41:15PM +0200, Matthias Kramm wrote:
> 
> > 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)

Do you have the patch available somewhere? If it is a libart bug, I
would like to submit it to fedora too.

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

Ok.

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

It is under review in fedora, but waiting for the version 4 release.
Is it patched in swftools, or would upstream ming be right?

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

Ok.

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

I know that, but my question was, would you accept patches to be able to
compile against system gocr and/or libart, and if yes, what design would
you prefer?

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

Indeed, but using old library is only a temporary workaround, which may
be suitable for you as swftools maintainer, but not in a distribution.
In a distribution, the bugs should be fixed where they are instead of
avoiding regressions. More to th epoint, testing version of the
distribution are there to find out regressions, so they shouldn't be
hidden (and hopefully fixed before the release...). Also in a
distribution bugs should be filtered by the package maintainer such that
he can triage what is a library and an application bug.

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

I would have said the reverse... poppler should have a more well-defined
API, and so it should be easier to use poppler than use xpdf source,
since in xpdf there is no API.
 
> The changes are also quite large- take a look at
> lib/pdf/xpdf-changes.patch for details.

Indeed, I saw it. It is big, but not that much.

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

That was not my point. My point was that maybe poppler needed to export
more xpdf symbols to be usable by swftools.

But in fact it seems that you extend th expdf 'API', so it would also
require extending the poppler API, but not only by exporting more xpdf
symbols, but also other symbols.

--
Pat