[poppler] Kpdf patches status
Albert Astals Cid
tsdgeos at yahoo.es
Mon May 2 15:27:19 PDT 2005
A Dilluns 02 Maig 2005 20:04, Kristian Høgsberg va escriure:
> 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.
I agree this belongs to the qt frontend as stated in the wiki
> "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
Don't know why such a simple thing, that already has a patch working again
poppler code has to go to the frontends, isn't code duplication bad?
> "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.
I don't agree in hardcoding it to the wrapper, IMHO it is the application that
has to provide the plugabble error function, someone may even want to show
all error in a popup. So my suggestion is include my patch and let the
application to the rest if it wants to do it.
> 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.
I would prefer building first against the poppler tree and to the change after
> About the UTF-8 patch - this wasn't added because the evince guys
> requested it, as you write, rather because a bug 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.
I had already verified first hand that it fixed a problem, you just had to ask
for a test case, you did not.
>  https://bugs.freedesktop.org/show_bug.cgi?id=2934
More information about the poppler