[poppler] poppler 0.5.4 coming up
krh at bitplanet.net
Thu Sep 21 15:32:58 PDT 2006
On 9/21/06, Kouhei Sutou <kou at cozmixng.org> wrote:
> In <59ad55d30609201451g54965822u1293cf880e799688 at mail.gmail.com>
> "[poppler] poppler 0.5.4 coming up" on Wed, 20 Sep 2006 17:51:48 -0400,
> "Kristian_Høgsberg" <krh at bitplanet.net> wrote:
> > So it's about time for a new release
> It's good news!
> > There's a bunch of important fixes in CVS and the release is long
> > overdue so I'd really like to get this out tomorrow at the latest, but
> > if there's a show-stopper bug you know of that should get fixed before
> > the release, let me know.
> I have some bugs I filed.
> * PopplerAction family is not GLib-ish
> 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.
> * make PopplerFontInfo GObject
> 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
> * It's better PopplerPage manages PopplerDocument's reference count
Makes sense, I've merged this one for 0.5.4.
More information about the poppler