Opened 8 years ago
Closed 8 years ago
#295 closed task (fixed)
Build against poppler 0.47.0
Reported by: | Lewis Rosenthal | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Plugin: PDF | Version: | 1.3.6 |
Keywords: | Cc: |
Description
poppler 0.47.0 just landed (popple63.dll).
Too bad we need to rebuild each time. I tried symlinking popple63.dll to popple59.dll, but alas, no go.
Attachments (1)
Change History (20)
comment:2 by , 8 years ago
Thanks for the tip, Silvan. This has been annoying me for some time, now, as the whole reason for splitting poppler out from the main distribution was to enable us to take advantage of your new poppler releases.
comment:4 by , 8 years ago
ANPM is lying to you. ;-)
I just installed poppler-cpp-devel-0.47.0-1.oc00.pentium4. Select 0.38.0-1, and ANPM will pull the latest one.
comment:5 by , 8 years ago
In any event, I guess the point is that building against *-cpp will look for the latest popplxx.
comment:6 by , 8 years ago
This doesn't give the slightest inkling of how one might go about using it. Any suggestions?
comment:7 by , 8 years ago
If you build against the cpp backend, you don't have to worry about poppler changes. As the backends are stable since longer. In theory all functions are available, but are called different. I have no idea how good the documentation of the cpp backend is.
comment:8 by , 8 years ago
For reference:
http://marpirk.github.io/poppler-cpp-doc/ (official documentation)
I am still looking for useful examples.
comment:9 by , 8 years ago
That document is basically a rewrite of the header files without any additional explanations. The headers mostly lack comments.
comment:10 by , 8 years ago
Agreed. As I said, I was only adding that for reference. I'm rather surprised that the poppler docs are so sparse, when so many people and projects use it.
Have a look at:
https://cgit.freedesktop.org/poppler/poppler/tree/cpp/tests/poppler-dump.cpp https://cgit.freedesktop.org/poppler/poppler/tree/cpp/tests/poppler-render.cpp
At least they're working examples.
comment:11 by , 8 years ago
Ok I can see I can replace some (most?) poppler calls directly with poppler-cpp calls. However, poppler-cpp appears to only contain a subset of poppler calls. For example it lacks:
GooString *getSubstituteName() { return substituteName; }; We use this one
GooString *getEncoding() { return encoding; };
GBool getToUnicode() { return hasToUnicode; };
Ref getRef() { return fontRef; };
Ref getEmbRef() { return embRef; };
in FontInfo. This will mean a reduced feature set following a lot of work (assuming I don't encounter a missing feature we can't do without and that I can actually do this) in trade for not needing to rebuild. I may have found one of a very few places features are missing but it doesn't bode well since it was the first thing I looked at. Assuming there are only a couple we could probably add them to poppler-cpp but unless we could get them accepted upstream it would be a pain to maintain.
comment:12 by , 8 years ago
Hmmm... So:
http://marpirk.github.io/poppler-cpp-doc/classpoppler_1_1font__info.html
will not provide what we need for this? It would have to be implemented differently, but it appears that the method is there. It seems to me that this would be a pretty glaring omission if one could not extract this information.
comment:13 by , 8 years ago
I looked it would be half a dozen lines of code to add this one (getSubstituteName) to poppler-cpp. Unfortunately, I have no way of knowing if this is the only one that we use that is missing or if lots of them are missing. If we can easily get our updates to poppler-cpp upstream it might be worth trying this but if we can't we basically end up with the same rebuild problem just at a different level. If we wanted to use any new features that poppler might introduce we would probably need to add them to poppler-cpp since I doubt they are consistently doing so. This would be double work for updating as we would still have to then add them to Lucide.
What are the restrictions on the glib front end?
by , 8 years ago
Attachment: | poppler-font.h added |
---|
comment:14 by , 8 years ago
Lewis
Attached is the actual header file from poppler-cpp 0.47.0 as you can see getSubstituteName is not present. I can't get github to load so I can't look at your link. I have had nothing but problems getting github to load with recent versions of Seamonkey and Firefox. Any suggestions? Thanks
comment:15 by , 8 years ago
It is possible that one of the poppler forks is doing more active development of poppler-cpp and has included getSubstituteName and more. Even if this is true how do we update it relative to the poppler we are using?
comment:16 by , 8 years ago
I don't see any recent forks of poppler, unfortunately.
I do understand how the lack of such features in the cpp frontend can be frustrating.
Let's consider a switch to the cpp frontend as a longer term goal, when we see more of what we want included in it (either from our suggesting or from others), and in the meantime stick to what we're doing now.
What this means is that we are back to ensuring that a poppler upgrade does not break an otherwise-working solution, but I have some ideas about that which I will add to the proper ticket.
comment:17 by , 8 years ago
We have another choice. I can add getSubstituteName to poppler-cpp. Then open a ticket and attach the fix and see what they do with it. In any event the change to cpp needs to be done in a branch. I can hopefully replace poppler headers with cpp headers one at a time and be able to build and test on each change. As for this being a longer term goal I agree.
comment:19 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Closing this as resolved, because the original issue (building against poppler 0.47.0) has been done. We can open further tickets for the next poppler update and for the RFE to build using poppler-cpp.
Thats only true because Lucide uses the wrong backend. If it uses the poppler-cc backend, then no need to rebuild. Like with qpdfview. It uses the qt4 backend and those are stable.