[poppler] Kpdf patches status

[Albert Astals Cid]

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
> preferences.
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 
to poppler-qt

> 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.
I had already verified first hand that it fixed a problem, you just had to ask 
for a test case, you did not.

Albert

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