Re: G::O::I based bindings and problem passing char array ref

"Torsten Schoenfeld" > So I think at this point it would be best to create a bug report against > poppler. I found an old bug report about this very issue: . It was closed as invalid, but I think that was due to a misunderstanding. So I reop

Re: G::O::I based bindings and problem passing char array ref

On 03.06.2016 21:44, Jeremy Volkening wrote: > Attached is the valgrind dump from my test script. This is after > changing the section of the .gir for poppler_document_new_from_data() > > FROM: > > > the pdf data contained in a char array > > > > TO: > > > the pdf data contained

Re: G::O::I based bindings and problem passing char array ref

> > If I futz with the .gir and change the new_from_data() "data" > > parameter type to a guint8 array (and then pass it a character > > array ref) I can load and read the page number from most of the > > files that were previously throwing errors. Then the script > > segfaults almost every time...

Re: G::O::I based bindings and problem passing char array ref

Of course, forgot to attach. Here is dump. On Fri, 3 Jun 2016 14:44:58 -0500 Jeremy Volkening wrote: > > > If I futz with the .gir and change the new_from_data() "data" > > > parameter type to a guint8 array (and then pass it a character > > > array ref) I can load and read the page number from

Re: G::O::I based bindings and problem passing char array ref

"Jeremy Volkening" : > > I see that the data argument to "new_from_data()" is specified as a > > utf-8 char array, but the contents of the PDF files (those that use > > compressed blocks) are not actually straight UTF-8. Is it possible > > that perl-G:I:O sees the specs and is forcing UTF-8 encodin

Re: G::O::I based bindings and problem passing char array ref

> > I see that the data argument to "new_from_data()" is specified as a > utf-8 char array, but the contents of the PDF files (those that use > compressed blocks) are not actually straight UTF-8. Is it possible > that perl-G:I:O sees the specs and is forcing UTF-8 encoding on the > data at some po

Re: G::O::I based bindings and problem passing char array ref

On Thu, 2 Jun 2016 21:09:51 -0500 Jeremy Volkening wrote: > This problem is a bit hard to grasp. More detailed tests on another > batch of PDFs gave this: > > 1. Most (126) failed to open with the "PDF document is damaged" error > > 2. A few (4) opened but failed to load the first page ( e.g. >

Re: G::O::I based bindings and problem passing char array ref

> > > > Can anyone else test that the above code does or doesn't work on > > their system? If it's just me I guess I won't worry about it too > > much, although I'd like to know why. > > I tried several files and I got "PDF document is damaged at > /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-th

Re: G::O::I based bindings and problem passing char array ref

On 2 June 2016 at 04:26, Jeremy Volkening wrote: >> > No - I get "PDF document is damaged at >> > /usr/lib/x86_64-linux-gnu/perl5/5.20/Glib/Object/Introspection.pm >> > line 58." >> > >> > What version of Poppler do you have? >> >> 0.41.0, and G:O:I from Git, but I don't think there were any recen

Re: G::O::I based bindings and problem passing char array ref

On Wed, 1 Jun 2016 22:39:45 +0200 Torsten Schoenfeld wrote: > On 31.05.2016 20:07, Jeremy Volkening wrote: > >> Since new_from_data is currently not annotated to take an array of > >> bytes, a normal string should work fine in Perl. This works for > >> me: > >> > >> --- > >> use Glib::Object::In

Re: G::O::I based bindings and problem passing char array ref

> >> warn my $d = Poppler::Document->new_from_data ($data, length > >> $data); --- > >> > >> Does it not work for you? > > > > No - I get "PDF document is damaged at > > /usr/lib/x86_64-linux-gnu/perl5/5.20/Glib/Object/Introspection.pm > > line 58." > > > > What version of Poppler do you have? >

Re: G::O::I based bindings and problem passing char array ref

On 31.05.2016 20:07, Jeremy Volkening wrote: >> Since new_from_data is currently not annotated to take an array of >> bytes, a normal string should work fine in Perl. This works for me: >> >> --- >> use Glib::Object::Introspection; >> BEGIN { >> Glib::Object::Introspection->setup ( >> basena

Re: G::O::I based bindings and problem passing char array ref

> Since new_from_data is currently not annotated to take an array of > bytes, a normal string should work fine in Perl. This works for me: > > --- > use Glib::Object::Introspection; > BEGIN { > Glib::Object::Introspection->setup ( > basename => 'Poppler', > version => '0.18', > pack

Re: G::O::I based bindings and problem passing char array ref

On 10.04.2016 20:48, Jeremy Volkening wrote: > A few months ago I updated the Poppler module to use > Glib::Object::Introspection to generate the bindings. I just realized > yesterday that this broke the "new_from_data()" constructor. I realized > this as I was wrapping librsvg 2.0 in a similar fas

Re: G::O::I based bindings and problem passing char array ref

> The @data argument should be marked as an array, with length stored in > the @length argument, i.e.: > > @data: (array length=length): the pdf data contained in a char array > > This will allow the introspection bindings to know that you're passing > an array with a specified length, instead o

Re: G::O::I based bindings and problem passing char array ref

Hi; the C symbol is lacking introspection annotations: /** * poppler_document_new_from_data: * @data: the pdf data contained in a char array * @length: the length of #data * @password: (allow-none): password to unlock the file with, or %NULL * @error: (allow-none): Return location for an err

G::O::I based bindings and problem passing char array ref

Hello, A few months ago I updated the Poppler module to use Glib::Object::Introspection to generate the bindings. I just realized yesterday that this broke the "new_from_data()" constructor. I realized this as I was wrapping librsvg 2.0 in a similar fashion (https://github.com/jvolkening/p5-Image-