On Sat, 2017-03-04 at 08:02 -0700, Sean Whitton wrote: > Dear Jason, > > On Sat, Mar 04, 2017 at 12:00:19AM -0600, Jason Crain wrote: > > If you're going to adopt the Xpdf package, I thought you might want > > to > > know a little about Xpdf first and why the Debian package is the > > way > > that it is. The Debian package modifies Xpdf to make it use > > poppler > > (https://poppler.freedesktop.org) for rendering instead of using > > it's > > own internal code. I think this was done for security and bug > > fixes, > > and because the poppler upstream is more responsive than Xpdf. > > > > Poppler is a fork of Xpdf. Before poppler, it was common for > > applications which wanted to read PDFs to embed a copy of the Xpdf > > code. > > Poppler was created to turn sections of the Xpdf code into a > > library so > > that it could be more easily reused, to have a centralized place > > for > > development, and to put APIs over the code.
I know about all this already. In fact I did port the code in January 2014 when it (3.03-11) was about to be removed from testing for Jessie. See the thread starting at https://lists.debian.org/debian-devel/2014/0 1/msg00254.html. These patches were not needed/accepted since somebody else had done the same work resulting in version 3.03-12. (I was never asked to publish my patches, and I did not check them versus the ones that went into the Debian package.) > > Debian's Xpdf is significantly different from upstream Xpdf. The > > package has build rules and patches which modify the code to be > > compatibile with poppler. Also, since the poppler devs do not > > guarantee > > stability for the old Xpdf functions, because those functions were > > never > > intended to be a stable interface, the patches will occasionally > > need to > > be modified to match any changes in poppler. This is the big problem, the two code bases are diverging. See a good description about the status of xpdf from December 2013: https://www.agwa.name/blog/post/the_sorry_state_of_xpdf_in_debian After my asking around to poppler and upstream Glyph & Cog, LLC, in the name of Derek B. Noonburg, created a new upstream release, 3.04. See the CHANGES file (changelog in the debian package) in the upstream tarball for the latest fixes. However, Debian chose to continue trying to catch up with the patches to libpoppler, in my opinion a very bad choice. The current state is really bad, most of the bugs are due to the use of the libpoppler backend. > Thank you very much for this input, Jason. > > It sounds like the source should not in fact be repacked. What do > you > think, Svante? The solution I've chosen is to remove the poppler backend completely. That fixes 11+ important and normal bugs (and probably many minor and wishlist ones too, I haven't looked into that yet) If somebody wants a poppler-based xpdf, it should be renamed to something else, e.g. ppdf, and maybe even be integrated in the poppler upstream code. Trying to merge xpdf frontend with the poppler backend is just a loosing battle. Just to give you a look into what I've done, I uploaded xpdf-3.04.real- 5 to mentors.debian.net. (Some minor changes are still needed I think, before I'm happy with the result). As said before: debdiff is not possible to use against 3.04-4, but it is with 3.04.real-4 and 3.04-5. Thanks for your attention, Svante