PoDoFo FAQ

Yes, though you must follow the terms of the LGPL license for PoDoFo. The license permits you to use PoDoFo in any commercial application, though the LGTL obliges you to provide source to PoDoFo its self and any changes you made to it under the LGPL. That means that you may link code to PoDoFo that is not GPL or LGPL licensed so long as you follow the LGPL's rules. You need not fear "viral code" here - not unless you start copying chunks of podofo into your own application, of course. The inlining done by the compiler is considered "linking" for the purposes of the license and thus not an issue.

The PoDoFo developers would be happy if you would credit them for using PoDoFo in your application, though this is not a license obligation.

PoDoFo is not presently able to provider either a stable API or ABI. The library is being developed quickly and still requires a lot of changes to its interfaces as it is enhanced.

At present the best option for many users will be to target a snapshot of PoDoFo or a particular release. An in-tree copy of the library is not an unreasonable option, though care must be taken to ensure that your copy doesn't end up as an increasingly unmaintainable fork. The svn:externals mechanism is probably ideal for projects that use svn, since it lets you specify a particular tag or revision that's versioned along with your project. See PoDoFoBrowser for an example of this.

The README offers some more information on how to minimise the impact of API changes on your application.

The PoDoFo developers are interested in offering a stable, maintained release at some point, but the library is not yet at a point where that is practical.

PoDoFo can not be used directly from a basic C program, but if you have access to a C++ compiler there are acceptable workarounds.

The cleanest approach is probably to write your PoDoFo-using code as C++ and have it expose a pure C interface (using extern "C" and the nothrow() qualifier) that can be used by the rest of your program/library/plugin. With proper care and attention to memory handling and exception safety in the code that works directly with podofo, this approach should work extremely well. You need to be careful not to allow exceptions to unroll past your interface functions and into their pure-C callers, and it's also necessary to be careful to use the C library memory allocator when allocating memory that'll be free()'d in your pure C code (or vice versa).

As an alternative, if your program compiles as C++ (most C programs are legal C++), you may simply switch to building it with a C++ compiler. You may then use PoDoFo directly, though you'll still need to pay attention to cleaning up after an exception is thrown to avoid leaking resources or leaving your program in an invalid state. This is a reasonable approach for stand-alone programs, but is unattractive for library authors, plugin writers for C programs, and some other users.

Not as yet.

As PoDoFo does not make heavy use of templates in its general public API, it would be possible to write a fairly full featured C wrapper around PoDoFo's public C++ APIs. Most of what'd be needed would be to:

• provide factory functions for PoDoFo objects
• provide deletion functions for PoDoFo objects
• write wrappers for methods that take an instance as their first argument (also expanding overloaded methods) and translate thrown exceptions into error codes.

The PoDoFo authors would be interested in hearing about any such effort, but are not working on anything along those lines themselves.

If you're seeing a traceback including a call to std::terminate(), like the (simplified) one shown below, the problem is probably that you're not catching an exception being thrown by podofo.

raise()
abort ()
std::set_unexpected ()
std::terminate ()
PoDoFo::SomePoDoFoMethod()
main()


PoDoFo uses exceptions to indicate error conditions to the caller, and your program is not handling an exception that is thrown by PoDoFo. Your program should call all PoDoFo methods that are not annotated `nothrow()' in a try/catch block, or be prepared to handle the exception further up the call chain. Code that calls PoDoFo should also be exception safe.

In simplified terms, if you fail to catch an exception and allow it to unroll the stack past your main() function, the runtime will call std::terminate() for you. This in turn will call abort(). On Linux, a SIGABRT (Signal #6) will be generated and your program will be terminated. Windows users may be informed that their program has asked the runtime to terminate it in an unusual way, or may get a crash dialog.