[poppler] Proposed changes

[Kristian Høgsberg]

(Oops, sent this one off before I finished it)

On Fri, 2005-03-04 at 11:43 -0500, Kristian Høgsberg wrote:
>On Fri, 2005-03-04 at 09:31 +0100, Albert Astals Cid wrote:
>>That is a thing we should discuss deeply. Do we want a complete fork or do we 
>>want a fork where apply fixes but keep close enough to xpdf sources so we can 
>>easily merge future xpdf releases?

Yes, this is a topic I've wanted to bring up.  We need to discuss and
agree on the scope of the work we want to do here, what kind of changes
we want to make to poppler.  I basically agree with you, Albert, that we
should avoid big changes that make the code diverge too much from xpdf.
We don't want to make it too difficult to merge bug fixes between
poppler and xpdf, and a patch to use the C++ builtin bool type doesn't
buy us much, but creates a lot of diff noise.  Also, I think we need to
stay clear of "political dependencies" such as Qt and glib.  There is
already a string class and a couple of container classes in there, well
tested and integrated with the rest of the code.

When I mention in the TODO that we should try to reuse existing
infrastructure as much as possible, I'm mainly thinking of the ways the
library interacts with the rest of the system: how does it find it's
fonts, how does it look up its configuration options.  We really don't
want another font location mechanism on the system, so we should
integrate the kpdf fontconfig support and try to get rid of /etc/xpdfrc.

Second, when it makes sense, we can try to swap out big chunks of the
code for standard libraries.  This is second priority since it doesn't
affect the behavior of the library, and there currently is a working
implementation in xpdf.  Jeff Muizelaar has a patch to implement the
DCTStream using libjpeg, which makes a lot of sense to me, since the
xpdf DCTStream probably hasn't had a lot of audit, and it is a security
sensitive area.  Jeff, could you resend you patches to the list?

Finally, the cairo backend is special, since we're not just replacing
functionality with a standard library, here's a chance to significantly
improve over xpdf in terms of quality, supported PDF features and speed,
while removing 6000 lines of code.

>>My opinion, unless we have much [wo]man power to develop on our own, we should 
>>keep close to xpdf sources and that rules out that "heavy" changes Wilco 
>>proposes.
>>
>>I mean, if in the future comes out xpdf 4.0, it is much better than poppler 
>>and it can not be merged, the most probable thing is that i would make KPDF 
>>use xpdf sources again.

That's quite understandable.  Though, I do hope that if/when that time
comes, we will able to merge the new version into poppler, or if that is
not possible, create a new library fork for xpdf-4.0.

[...]

>>> The autogen.sh didn't work for me. I've copied one from cairo and changed
>>> it a bit. I've attached it to this email.

I forgot the -i option to autoreconf in the first version.  Does the
current CVS work for you?

cheers,
Kristian