A Divendres, 5 de novembre de 2010, Tim Brody va escriure: > On Thu, 04 Nov 2010 18:55:25 -0000, Albert Astals Cid <[email protected]> > > wrote: > > A Dijous, 4 de novembre de 2010, Tim Brody va escriure: > >> On Wed, 2010-11-03 at 18:52 +0000, Albert Astals Cid wrote: > >> > A Dimecres, 3 de novembre de 2010, Tim Brody va escriure: > >> > > I've reworked my SWIG wrapper into a patch (attached). > >> > > > >> > > I'm no expert on automake and pretty new to SWIG - I've > >> > >> copy-n-pasted > >> > >> > > most of the SWIG stuff from Xapian. > >> > > >> > I'm not sure if you are aiming for inclusion in mainline poppler or > >> > >> just > >> > >> > want to share your patch. > >> > > >> > If you aim for inclusion in poppler, i'm sorry but we don't want > >> > >> people > >> > >> > using the internal core structures so we can't accept your patch. You > >> > should be using any of the three public frontends qt/glib/cpp > >> > >> The 0.12 front-ends don't do what I require: > >> 1) Search PDF for patterns of words (or regexp a single word) > >> 2) Add link annotations > >> (And in 0.15 retrieving all text with positional data is very > >> inefficient - re-display() for every word?) > > > > Then you have two options: > > * We do not commit your patch and you apply it locally for your uses. > > * You send a patch to make the frontends do what you need. > > > > Note that 0.12 is old and you shouldn't be using it. > > 0.12 is the current release on Ubuntu/Fedora 13 (0.5 on RHEL5!).
So? 0.12 is still old and should not be used for development. > For my > current needs I'll just wrap the core classes, for reasons outlined below > I don't want to put the effort into wrapping front-ends yet. Ok, then it'll just won't be added into poppler. Good luck with your needs. > > >> Basically I'm sruck with the same concern here: > >> http://lists.freedesktop.org/archives/poppler/2006-January/001522.html > > > > Care to elaborate? > > The front-ends provide APIs for rendering PDF, whereas the core classes > also provide a PDF API. Because noone added a good API in the frontends to modify the PDF. > If I wanted to add/use an > attribute that isn't in the PDF spec. would poppler add accessors for that? Don't understand the question. > Putting aside my specific application and thinking about SWIG bindings. In > glib I find_text() whereas in cpp I search(). In qt4 I can textList() but > in cpp I can only text(). > > IMHO you should define an API that is neutral which you then wrap > (consistently) in glib, qt, etc. Perhaps this is what cpp will be? No, cpp is just another frontend. > But > unlike cpp I absolutely want to have access to the PDF API and, from an OO > perspective: > Object -> Dictionary -> Page > (not Page(Object(Dictionary))) As said, patches to the frontends are welcome. > When adding functionality you can then add it to the API rather than > trying to patch xpdf while maintaining upstream compatibility. Don't understand this sentence at all. Albert _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
