error: 'class PDFDoc' has no member named 'getPDFVersion'
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
Hi there,
I am trying to compile against libpoppler and I am getting the following compiler error: /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx: In function 'int ProcessOneFile(const std::string&, const gdcm::Defs&)': /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx:480: error: 'class PDFDoc' has no member named 'getPDFVersion' Why has the function been removed. It seems to be me that only the minor version has been changed, right ? Thanks, -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
On Thu, Nov 12, 2009 at 5:02 PM, Mathieu Malaterre
<mathieu.malaterre@...> wrote: > Hi there, > > I am trying to compile against libpoppler and I am getting the > following compiler error: > > /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx: In function > 'int ProcessOneFile(const std::string&, const gdcm::Defs&)': > /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx:480: error: > 'class PDFDoc' has no member named 'getPDFVersion' > > Why has the function been removed. It seems to be me that only the > minor version has been changed, right ? Looks like it broke in some other place: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529331 How do I check the poppler version ? I cannot simply try-compile every-single function to check which one disapear during a minor version change. Thanks for suggestion, -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
|
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Dominic Lachowicz
::
Rate this Message:
Just because a method is included in the "public" part of the class
doesn't mean that it's part of poppler's supported, public API (i.e. meant to be used by 3rd-party users). The XPDF headers aren't installed by default - you need to configure with '--enable-xpdf-headers' to have them installed. I believe that the recommended way of using poppler is through either the Qt or Glib bindings. On Thu, Nov 12, 2009 at 11:34 AM, Mathieu Malaterre <mathieu.malaterre@...> wrote: > this has always been in the public: section of PDFDoc class. Where do > you see being protected/private ? > > http://gnunet.org/libextractor/doxygen/html/classPDFDoc.html#99095156274a44f39aedb9b0cdb6b300 > > On Thu, Nov 12, 2009 at 5:21 PM, Dominic Lachowicz > <domlachowicz@...> wrote: >> You're using a non-public API. Stuff like this happens when you do that. >> >> On Thu, Nov 12, 2009 at 11:15 AM, Mathieu Malaterre >> <mathieu.malaterre@...> wrote: >>> On Thu, Nov 12, 2009 at 5:02 PM, Mathieu Malaterre >>> <mathieu.malaterre@...> wrote: >>>> Hi there, >>>> >>>> I am trying to compile against libpoppler and I am getting the >>>> following compiler error: >>>> >>>> /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx: In function >>>> 'int ProcessOneFile(const std::string&, const gdcm::Defs&)': >>>> /tmp/buildd/gdcm-2.0.14/Applications/Cxx/gdcminfo.cxx:480: error: >>>> 'class PDFDoc' has no member named 'getPDFVersion' >>>> >>>> Why has the function been removed. It seems to be me that only the >>>> minor version has been changed, right ? >>> >>> Looks like it broke in some other place: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529331 >>> >>> How do I check the poppler version ? I cannot simply try-compile >>> every-single function to check which one disapear during a minor >>> version change. >>> >>> Thanks for suggestion, >>> -- >>> Mathieu >>> _______________________________________________ >>> poppler mailing list >>> poppler@... >>> http://lists.freedesktop.org/mailman/listinfo/poppler >>> >> >> >> >> -- >> "I like to pay taxes. With them, I buy civilization." -- Oliver Wendell Holmes >> > > > > -- > Mathieu > -- "I like to pay taxes. With them, I buy civilization." -- Oliver Wendell Holmes _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
On Thu, Nov 12, 2009 at 5:48 PM, Dominic Lachowicz
<domlachowicz@...> wrote: > Just because a method is included in the "public" part of the class > doesn't mean that it's part of poppler's supported, public API (i.e. Of course it is, this is exactly the definition. If you do not want to expose it, put it in the protected section and make class friend. This is basic C++. > meant to be used by 3rd-party users). The XPDF headers aren't > installed by default - you need to configure with > '--enable-xpdf-headers' to have them installed. I do not know those implementation details. > I believe that the recommended way of using poppler is through either > the Qt or Glib bindings. This has absolutely nothing to do here. This is a matter of respection versioning. Apparently work is properly done at library level and SONAME/SOVERSION have been updated, all I am looking for is the same at API level (ie. reflect the change of ABI/API, at code level). This is a very basic question: how does client application level cope with an API incompatible change (this is a naive question, I could not find the proper #ifdef) Thanks, -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Dominic Lachowicz
::
Rate this Message:
On Thu, Nov 12, 2009 at 12:03 PM, Mathieu Malaterre
<mathieu.malaterre@...> wrote: > On Thu, Nov 12, 2009 at 5:48 PM, Dominic Lachowicz > <domlachowicz@...> wrote: >> Just because a method is included in the "public" part of the class >> doesn't mean that it's part of poppler's supported, public API (i.e. > > Of course it is, this is exactly the definition. If you do not want to > expose it, put it in the protected section and make class friend. This > is basic C++. Or, alternately, one could choose not to install the headers and mark their use as "caveat emptor". >> I believe that the recommended way of using poppler is through either >> the Qt or Glib bindings. > > This has absolutely nothing to do here. This is a matter of respection > versioning. Apparently work is properly done at library level and > SONAME/SOVERSION have been updated, all I am looking for is the same > at API level (ie. reflect the change of ABI/API, at code level). If something is not considered to be part of the public API, then there's nothing to respect. What you need to respect is what the developers declare to be public, supported API. Which, in this case, are the Glib and Qt bindings. Best, Dom _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
On Thu, Nov 12, 2009 at 6:11 PM, Dominic Lachowicz
<domlachowicz@...> wrote: > On Thu, Nov 12, 2009 at 12:03 PM, Mathieu Malaterre > <mathieu.malaterre@...> wrote: >> On Thu, Nov 12, 2009 at 5:48 PM, Dominic Lachowicz >> <domlachowicz@...> wrote: >>> Just because a method is included in the "public" part of the class >>> doesn't mean that it's part of poppler's supported, public API (i.e. >> >> Of course it is, this is exactly the definition. If you do not want to >> expose it, put it in the protected section and make class friend. This >> is basic C++. > > Or, alternately, one could choose not to install the headers and mark > their use as "caveat emptor". > >>> I believe that the recommended way of using poppler is through either >>> the Qt or Glib bindings. >> >> This has absolutely nothing to do here. This is a matter of respection >> versioning. Apparently work is properly done at library level and >> SONAME/SOVERSION have been updated, all I am looking for is the same >> at API level (ie. reflect the change of ABI/API, at code level). > > If something is not considered to be part of the public API, then > there's nothing to respect. What you need to respect is what the > developers declare to be public, supported API. Which, in this case, > are the Glib and Qt bindings. So you are saying I need the following, to open a PDF file and get its PDF Version : [ref: http://packages.debian.org/sid/libpoppler-glib-dev] * dep: hurd [hurd-i386] The GNU Hurd also a virtual package provided by hurd-udeb * dep: libc0.1 (>= 2.3) [kfreebsd-amd64, kfreebsd-i386] GNU C Library: Shared libraries also a virtual package provided by libc0.1-udeb * dep: libc0.3 (>= 2.9) [hurd-i386] GNU C Library: Shared libraries also a virtual package provided by libc0.3-udeb * dep: libc6 (>= 2.2.5) [amd64] GNU C Library: Shared libraries also a virtual package provided by libc6-udeb dep: libc6 (>= 2.3.6-6~) [i386] dep: libc6 (>= 2.4) [armel, mips, mipsel, powerpc, s390] dep: libc6 (>= 2.5) [hppa] dep: libc6 (>= 2.5-5) [m68k] dep: libc6 (>= 2.6) [sparc] * dep: libc6.1 (>= 2.2) [ia64] GNU C Library: Shared libraries also a virtual package provided by libc6.1-udeb dep: libc6.1 (>= 2.4) [alpha] * dep: libcairo2 (>= 1.4) [m68k] The Cairo 2D vector graphics library dep: libcairo2 (>= 1.8.4) [not m68k] * dep: libcairo2-dev (>= 1.4) [m68k] Development files for the Cairo 2D graphics library dep: libcairo2-dev (>= 1.8.4) [not m68k] * dep: libfontconfig1 (>= 2.4.0) generic font configuration library - runtime * dep: libfreetype6 (>= 2.2.1) FreeType 2 font engine, shared library files * dep: libgcc1 (>= 1:4.1.1) [not armel, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, m68k] GCC support library dep: libgcc1 (>= 1:4.4) [kfreebsd-amd64, kfreebsd-i386] dep: libgcc1 (>= 1:4.4.0) [armel] dep: libgcc1 (>= 4.2.1) [hurd-i386] * dep: libgcc2 (>= 4.2.1) [m68k] Package not available * dep: libgcc4 (>= 4.1.1) [hppa] GCC support library * dep: libglib2.0-0 (>= 2.16.0) The GLib library of C routines * dep: libglib2.0-dev (>= 2.12) [not m68k] Development files for the GLib library dep: libglib2.0-dev (>= 2.6) [m68k] * dep: libgtk2.0-0 (>= 2.12) [not m68k] The GTK+ graphical user interface library dep: libgtk2.0-0 (>= 2.12.0) [m68k] * dep: libjpeg62 The Independent JPEG Group's JPEG runtime library * dep: liblcms1 (>= 1.15-1) [not m68k] Color management library * dep: libopenjpeg2 JPEG 2000 image compression/decompression library * dep: libpango1.0-0 (>= 1.14.0) Layout and rendering of internationalized text * dep: libpango1.0-dev Development files for the Pango * dep: libpng12-0 (>= 1.2.13-4) [not m68k] PNG library - runtime * dep: libpoppler-dev (= 0.10.5-1) [m68k] PDF rendering library -- development files dep: libpoppler-dev (= 0.12.0-2) [not alpha, armel, i386, kfreebsd-amd64, kfreebsd-i386, m68k, sparc] dep: libpoppler-dev (= 0.12.0-2.1) [alpha, armel, i386, kfreebsd-amd64, kfreebsd-i386, sparc] * dep: libpoppler-glib4 (= 0.10.5-1) [m68k] PDF rendering library (GLib-based shared library) dep: libpoppler-glib4 (= 0.12.0-2) [not alpha, armel, i386, kfreebsd-amd64, kfreebsd-i386, m68k, sparc] dep: libpoppler-glib4 (= 0.12.0-2.1) [alpha, armel, i386, kfreebsd-amd64, kfreebsd-i386, sparc] * dep: libpoppler4 [m68k] PDF rendering library * dep: libpoppler5 [not m68k] PDF rendering library * dep: libstdc++6 (>= 4.1.1) [not kfreebsd-amd64, kfreebsd-i386] The GNU Standard C++ Library v3 dep: libstdc++6 (>= 4.4) [kfreebsd-amd64, kfreebsd-i386] * dep: libunwind7 [ia64] A library to determine the call-chain of a program - runtime * dep: libxml2 (>= 2.4.30) [mips] GNOME XML library dep: libxml2 (>= 2.6.27) [not mips] * dep: zlib1g (>= 1:1.1.4) compression library - runtime I did not realize how complex was the PDF format. Sigh... -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Vincent Torri-2
::
Rate this Message:
On Thu, 12 Nov 2009, Dominic Lachowicz wrote: > Just because a method is included in the "public" part of the class > doesn't mean that it's part of poppler's supported, public API (i.e. > meant to be used by 3rd-party users). The XPDF headers aren't > installed by default - you need to configure with > '--enable-xpdf-headers' to have them installed. no, They *have broken* API. Everything in the public part of the class is by definition in the API. Check for poppler >= 0.11.3, or better (as it's a release) poppler >= 0.12 Vincent Torri _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Mathieu Malaterre va escriure:
> On Thu, Nov 12, 2009 at 5:48 PM, Dominic Lachowicz > > <domlachowicz@...> wrote: > > Just because a method is included in the "public" part of the class > > doesn't mean that it's part of poppler's supported, public API (i.e. > > Of course it is, this is exactly the definition. If you do not want to > expose it, put it in the protected section and make class friend. This > is basic C++. > > > meant to be used by 3rd-party users). The XPDF headers aren't > > installed by default - you need to configure with > > '--enable-xpdf-headers' to have them installed. > > I do not know those implementation details. > > > I believe that the recommended way of using poppler is through either > > the Qt or Glib bindings. > > This has absolutely nothing to do here. This is a matter of respection > versioning. Apparently work is properly done at library level and > SONAME/SOVERSION have been updated, all I am looking for is the same > at API level (ie. reflect the change of ABI/API, at code level). > > This is a very basic question: how does client application level cope > with an API incompatible change (this is a naive question, I could not > find the proper #ifdef) And the very basic answer is that we don't support usage of those classes. Albert > > Thanks, > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Vincent Torri va escriure:
> On Thu, 12 Nov 2009, Dominic Lachowicz wrote: > > Just because a method is included in the "public" part of the class > > doesn't mean that it's part of poppler's supported, public API (i.e. > > meant to be used by 3rd-party users). The XPDF headers aren't > > installed by default - you need to configure with > > '--enable-xpdf-headers' to have them installed. > > no, They *have broken* API. Everything in the public part of the class is > by definition in the API. > > Check for poppler >= 0.11.3, or better (as it's a release) poppler >= 0.12 Whatever you like, it's already been said a million times you are on your own if you use poppler/ headers, complain as much as you want, this is not going to change. Albert > > Vincent Torri > _______________________________________________ > poppler mailing list > poppler@... > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Albert Astals Cid va escriure:
> A Dijous, 12 de novembre de 2009, Vincent Torri va escriure: > > On Thu, 12 Nov 2009, Dominic Lachowicz wrote: > > > Just because a method is included in the "public" part of the class > > > doesn't mean that it's part of poppler's supported, public API (i.e. > > > meant to be used by 3rd-party users). The XPDF headers aren't > > > installed by default - you need to configure with > > > '--enable-xpdf-headers' to have them installed. > > > > no, They *have broken* API. Everything in the public part of the class is > > by definition in the API. > > > > Check for poppler >= 0.11.3, or better (as it's a release) poppler >= > > 0.12 > > Whatever you like, it's already been said a million times you are on your > own if you use poppler/ headers, complain as much as you want, this is not > going to change. Of course, you are more than welcome in helping programming a toolkit agnostic C++ frontend for the poppler/ headers. Albert > > Albert > > > Vincent Torri > > _______________________________________________ > > poppler mailing list > > poppler@... > > http://lists.freedesktop.org/mailman/listinfo/poppler > > _______________________________________________ > poppler mailing list > poppler@... > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Martin Schröder
::
Rate this Message:
2009/11/12 Dominic Lachowicz <domlachowicz@...>:
> I believe that the recommended way of using poppler is through either > the Qt or Glib bindings. Seems so, since poppler is a PDF _rendering_ library (according to http://poppler.freedesktop.org). I think Mathieu needs a PDF _parser_ library. It's easy to make that out of poppler (we do it for pdftex/luatex/xetex) and I strongly suggest to make that an official flavour of poppler. Best Martin _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
On Thu, Nov 12, 2009 at 10:01 PM, Martin Schröder <martin@...> wrote:
> 2009/11/12 Dominic Lachowicz <domlachowicz@...>: >> I believe that the recommended way of using poppler is through either >> the Qt or Glib bindings. > > Seems so, since poppler is a PDF _rendering_ library (according to > http://poppler.freedesktop.org). > > I think Mathieu needs a PDF _parser_ library. It's easy to make that > out of poppler (we do it for pdftex/luatex/xetex) and I strongly > suggest to make that an official flavour of poppler. Ah... I think that's the root of my problem :) I thought poppler was *the* library for parsing PDF (extracted from xpdf). I am sorry to complain some more, but where do I see that such and such class are private implementation and should not be distributed (eg. debian ship those header files). Thanks, -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Martin Schröder va escriure:
> 2009/11/12 Dominic Lachowicz <domlachowicz@...>: > > I believe that the recommended way of using poppler is through either > > the Qt or Glib bindings. > > Seems so, since poppler is a PDF _rendering_ library (according to > http://poppler.freedesktop.org). > > I think Mathieu needs a PDF _parser_ library. It's easy to make that > out of poppler (we do it for pdftex/luatex/xetex) and I strongly > suggest to make that an official flavour of poppler. As i already said lots of times, we are interested in a plain C++ toolit agnostic frontend for poppler, still waiting for you guys to show up. Albert > > Best > Martin > _______________________________________________ > poppler mailing list > poppler@... > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Mathieu Malaterre va escriure:
> On Thu, Nov 12, 2009 at 10:01 PM, Martin Schröder <martin@...> wrote: > > 2009/11/12 Dominic Lachowicz <domlachowicz@...>: > >> I believe that the recommended way of using poppler is through either > >> the Qt or Glib bindings. > > > > Seems so, since poppler is a PDF _rendering_ library (according to > > http://poppler.freedesktop.org). > > > > I think Mathieu needs a PDF _parser_ library. It's easy to make that > > out of poppler (we do it for pdftex/luatex/xetex) and I strongly > > suggest to make that an official flavour of poppler. > > Ah... I think that's the root of my problem :) > I thought poppler was *the* library for parsing PDF (extracted from xpdf). > > I am sorry to complain some more, but where do I see that such and > such class are private implementation and should not be distributed > (eg. debian ship those header files). ./configure --help | grep xpdf --enable-xpdf-headers Install unsupported xpdf headers. Albert > > Thanks, > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by malat
::
Rate this Message:
On Thu, Nov 12, 2009 at 10:41 PM, Albert Astals Cid <aacid@...> wrote:
> A Dijous, 12 de novembre de 2009, Mathieu Malaterre va escriure: >> On Thu, Nov 12, 2009 at 10:01 PM, Martin Schröder <martin@...> wrote: >> > 2009/11/12 Dominic Lachowicz <domlachowicz@...>: >> >> I believe that the recommended way of using poppler is through either >> >> the Qt or Glib bindings. >> > >> > Seems so, since poppler is a PDF _rendering_ library (according to >> > http://poppler.freedesktop.org). >> > >> > I think Mathieu needs a PDF _parser_ library. It's easy to make that >> > out of poppler (we do it for pdftex/luatex/xetex) and I strongly >> > suggest to make that an official flavour of poppler. >> >> Ah... I think that's the root of my problem :) >> I thought poppler was *the* library for parsing PDF (extracted from xpdf). >> >> I am sorry to complain some more, but where do I see that such and >> such class are private implementation and should not be distributed >> (eg. debian ship those header files). > > ./configure --help | grep xpdf > --enable-xpdf-headers Install unsupported xpdf headers. Indeed the name is quite explicit. I've filled in a bug report against libpoppler-dev, this should get rid of similar issue on debian based-syste, from now on. http://bugs.debian.org/555959 Thanks, -- Mathieu _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Vincent Torri-2
::
Rate this Message:
On Thu, 12 Nov 2009, Albert Astals Cid wrote: > A Dijous, 12 de novembre de 2009, Vincent Torri va escriure: >> On Thu, 12 Nov 2009, Dominic Lachowicz wrote: >>> Just because a method is included in the "public" part of the class >>> doesn't mean that it's part of poppler's supported, public API (i.e. >>> meant to be used by 3rd-party users). The XPDF headers aren't >>> installed by default - you need to configure with >>> '--enable-xpdf-headers' to have them installed. >> >> no, They *have broken* API. Everything in the public part of the class is >> by definition in the API. >> >> Check for poppler >= 0.11.3, or better (as it's a release) poppler >= 0.12 > > Whatever you like, it's already been said a million times you are on your own > if you use poppler/ headers, complain as much as you want, this is not going > to change. i don't complain. I update my lib for each new release of poppler. You break the API often. Did you already read one of my mail about that ? I don't think so... Vincent Torri _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
|
|
Re: error: 'class PDFDoc' has no member named 'getPDFVersion'
by Albert Astals Cid-2
::
Rate this Message:
A Dijous, 12 de novembre de 2009, Vincent Torri va escriure:
> On Thu, 12 Nov 2009, Albert Astals Cid wrote: > > A Dijous, 12 de novembre de 2009, Vincent Torri va escriure: > >> On Thu, 12 Nov 2009, Dominic Lachowicz wrote: > >>> Just because a method is included in the "public" part of the class > >>> doesn't mean that it's part of poppler's supported, public API (i.e. > >>> meant to be used by 3rd-party users). The XPDF headers aren't > >>> installed by default - you need to configure with > >>> '--enable-xpdf-headers' to have them installed. > >> > >> no, They *have broken* API. Everything in the public part of the class > >> is by definition in the API. > >> > >> Check for poppler >= 0.11.3, or better (as it's a release) poppler >= > >> 0.12 > > > > Whatever you like, it's already been said a million times you are on your > > own if you use poppler/ headers, complain as much as you want, this is > > not going to change. > > i don't complain. I update my lib for each new release of poppler. You > break the API often. Did you already read one of my mail about that ? I > don't think so... It wasn't a particular "you", but a plural "you" as "in people out there". Albert > > Vincent Torri > _______________________________________________ > poppler mailing list > poppler@... > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list poppler@... http://lists.freedesktop.org/mailman/listinfo/poppler |
| Free embeddable forum powered by Nabble | Forum Help |
