[poppler] ANNOUNCE: gimp-poppler version 0.4.0

[Nathan Summers]

On 6/29/05, Kristian Høgsberg <krh at bitplanet.net> wrote:
> Nathan Summers wrote:
> > gimp-poppler version 0.4.0 has been released.  It can be downloaded at
> > http://rockwalrus.dyndns.org/~rockwlrs/gimp-poppler . This new version
> > features thumbnailing and the ability to only load individual pages.
> > There are other features; check the NEWS file for details.
> 
> Wow, good work, that's really nice.  Ideally, you shouldn't have to use
> the /usr/include/popper/* API, so I was looking through glib_glue.cc to
> see what kind of functionality we need to provide in the glib wrapper to
> avoid this.  First, the page label is actually available in the glib
> wrapper - it's probably not the most discoverable interface, but it's a
> GObject property.  So you can do
> 
>          char *label = NULL;
> 
>          g_object_get (G_OBJECT (poppler_page),
>                        "label", &label,
>                        NULL);
> 
> to get the label for a PopplerPage.

Yes, this was discovered by one of the gimp developers literally
minutes after I made the 0.4.0 release.  It's generally considered
good style for gobjects to provide a C accessor function for each
property, and vica-versa, for exactly this reason.

 > As for the anti-alias toggle... I'm not sure.  It's only affecting the
> fonts with the splash backend, right?  And the cairo backend can't
> respect that setting.  Is it really something you'd want to disable?

Generally, the ability to turn off antialiasing is not necessary or
desirable, but there are certainly image-manipulation situations where
having crisp, full-intensity borders is more important than subpixel
accuracy.  This is why pretty much every operation in GIMP can have
the antialiasing turned off.  It would be a shame if the poppler
plugin couldn't do this, when the old ghostscript-based plugin could.

> Getting at the paths and text in the PDF as you mention in your previous
> mail is a lot more difficult.  We can't easily get at that with the
> current poppler structure, and defining a good API for this isn't easy
> either.

We'll see what we can come up with.

> Anyway, it's great to see poppler and the glib wrapper used outside
> evince.  Let us know if there is more information you need from the
> poppler-glib API.

We'll stay in touch.

Rockwalrus