[poppler] poppler 0.5.4 coming up

[Kouhei Sutou]

Hi,

In <59ad55d30609211532s63d9d46fk556e5070b6645cd5 at mail.gmail.com>
  "Re: [poppler] poppler 0.5.4 coming up" on Thu, 21 Sep 2006 18:32:58 -0400,
  "Kristian_Høgsberg" <krh at bitplanet.net> wrote:

> > * PopplerAction family is not GLib-ish
> >   https://bugs.freedesktop.org/show_bug.cgi?id=6912
> >
> >   Now, I think this idea isn't good because GdkEvent uses
> >   same implementation. So I'll close this bug. Any opinion?
> 
> Closing is fine with me - I don't think the current union approach is
> a problem, and a GObject for this seems a bit heavy.  Besides the
> patch you've proposed breaks API so it's not for 0.5 anyway.

I closed.

I agreed with your opinion that a GObject is heavy.
# In language bindings, GObject is easy to wrap. This was the
# first motive for filing this request.

> > * make PopplerFontInfo GObject
> >   https://bugs.freedesktop.org/show_bug.cgi?id=6921
> >
> >   I'm the maintainer Ruby/Poppler. It's very easy to
> >   implement Ruby bindings if an object supports G_TYPE. I
> >   think it's a good idea that PopplerFontInfo supports
> >   GObject not GBoxed. Because PopplerFontInfo has a
> >   FontInfoScanner and FontInfoScanner doesn't have copy
> >   constructor. That is PopplerFontInfo's copy function can't
> >   copy current scan information. So, I think GObject is a
> >   good choice rather than GBoxed.
> 
> This is probably fine, but again, this breaks API, so I'd like to do
> this in 0.6.  I guess you could keep poppler_font_info_free() and just
> make it call g_object_unref() and not break API in that case.
> However, if we're going to break API in 0.6, we might as well punt
> this change for 0.6 and do it without the backwards compatible
> wrapper.

I see. I'll wait 0.6.

> > * It's better PopplerPage manages PopplerDocument's reference count
> >   https://bugs.freedesktop.org/show_bug.cgi?id=7005
> 
> Makes sense, I've merged this one for 0.5.4.

Thanks.


Regards,
--
kou