[poppler] Kpdf patches status

Kristian Høgsberg krh at bitplanet.net
Mon May 2 11:04:21 PDT 2005

Albert Astals Cid wrote:
> I've modified http://freedesktop.org/wiki/Software_2fpoppler to have KPDF - 
> poppler integration status table

Albert, thanks for collecting this list.  For what it's worth, I've had 
most of these mails marked as "TODO" in my inbox.  But as they say, the 
road to hell is paved with good intentions.  A better way to track these 
would be to put each patch in bugzilla and then create a kpdf-blocker 
bug in bugzilla that depends on these bugs.  That way we can easily see 
what's left to be done and we can discuss each of the patches in their 
bugzilla entry.

> Please comment on patches whose status is not "Done" becasue from people's 
> comments about poppler and freedesktop i'm beginning to have the feeling that 
> integrating kpdf is not that important for you.

No, getting kpdf to use poppler is important, this is still one of the 
goals of poppler.  But one of the things that's holding up this progress 
is that none of the poppler contributors are really qualified to write 
the qt bindings.  Jeff has done good job getting a first cut going, but 
in the end, it's the kpdf authors who knows qt best and knows what 
functionality kpdf needs.  A number of the missing patches really belong 
in the qt wrapper (I should have pointed this out earlier):

   "Display only some pages" - we don't have this functionality in 
poppler or glib.  With the glib API for printing you print one page at a 
time, and if you want to print a specific subset, you need to implement 
this in the application (kpdf/evince).  I think this API is sufficient, 
but we can add it in the qt wrapper if it is a kpdf blocker.

   "Read page transition" - most of this work need to take place in the 
qt wrapper.  Jonathan has been doing similar work for the glib wrapper. 
  Not transitions yet, but for page layout, page modes and viewer 

   "Plugable error function" - I agree that we need some way to control 
the warnings/errors printed by xpdf, and your patch looks good.  But 
again, the way we want to control the redirection differs from qt to 
glib.  For glib, I'd imagine we want some kind of g_warning integration 
and for qt I'm not sure.

Marco and Jonathan from the Evince project have contributed big parts of 
the glib API and have restructured evince in a number of ways to 
accomodate building against the poppler glib API.  I would love to see 
you guys chip in too and help build the qt API.

About the UTF-8 patch - this wasn't added because the evince guys 
requested it, as you write, rather because a bug[1] was filed about this 
issue, with a PDF that reproduced that problem.  It's a lot easier to 
apply a patch one you've verified first hand that it fixes a problem.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=2934

More information about the poppler mailing list