What platforms are supported by PoDoFo?
PoDoFo has been tested on Linux, Mac OS X and Windows. It is developed in a platform-independent way so that porting to any other system should be no problem.
Can I use PoDoFo in my commercial application?
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 LGPL obliges you to provide source to PoDoFo itself 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.
What language is PoDoFo written in?
PoDoFo is written entirely in C++. If you're interested in using it from other languages, see the section on those below.
Does PoDoFo offer a stable API or ABI?
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.
Does PoDoFo have a mailing list?
Yes. See our support pages. You're very welcome on the lists, and they're not high-traffic. If you have a question, make sure to tell us your compiler and version, platform / OS and version, PoDoFo version, where you got PoDoFo / how it was built, and the details of any error messages. If possible, upload a problem PDF document somewhere so that we can get to it, too.
My question isn't answered here. Where do I go next?
Your best bet is to email the podofo-users mailing list.
My program is written in C. Can I use PoDoFo?
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.
Is there a C wrapper for PoDoFo?
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:
The PoDoFo authors would be interested in hearing about any such effort, but are not working on anything along those lines themselves.
I'm a Java developer. Can I use PoDoFo?
Not with Java, no, though we don't discriminate if you've used it but want to move to another language ;-) . In all seriousness a wrapper for Java may be possible, but nobody has been in touch with the PoDoFo developers to express an interest in writing one. Java users will probably want to look at iText.
I'm a C# or other .NET developer. Can I use PoDoFo?
Not easily. Since PoDoFo is unmanaged C++ code, you can use it with P/Invoke and a glue layer, but I wouldn't recommend this as a pleasant way to use a library. If writing your PDF output code in C++ is an option, you may well be able to use PoDoFo.
Are any other languages supported?
No. Python bindings would be a fun Boost.Python project, though.
Sometimes my program crashes in a call to PoDoFo
and produces a traceback including a call to
std::terminate(). Why?
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.
Why does my program crash with a SIGABRT (Signal #6) in a call to PoDoFo?
You're probably not catching an exception being thrown by PoDoFo. See the answer for std::terminate. Alternately, you might be hitting an internal assertion in PoDoFo, indicating you've found a library bug. If your problem isn't covered by the answer for std::terminate, please report a bug and include the full PoDoFo library version, a backtrace of the crash (this is critical), the code that causes the crash if possible, the PDF document that causes the crash if possible, and full information about your platform (OS/distro and version, what the CPU is, etc).
Why does my program exit with the message "Application has requested runtime to terminate it in an unusual way" ?
This is the Windows equivalent of a crash on a signal. This could easily be an error in your code, or an error from PoDoFo
crashing your program. You need to attach a debugger to find out. If you're using MinGW, install GDB from this page under "GNU Source Level Debugger", then run gdb --args myprogram.exe. Visual Studio users should use the integrated debugger. If the crash does appear to come from PoDoFo, make sure that you are correctly catching and handling exceptions thrown by PoDoFo - see the answer to std::terminate.
PoDoFo creates invalid PDF files because , is used in floats instead of . Why?
PDF files use floating point numbers for almost all
drawing operations as coordinates. Those floating point numbers have to
be written in the English format with a . (point) as a separator.
Some languages like German use a , (comma) instead.
Earlier versions of PoDoFo used the current locale's C++ library formatting
operations to output values, causing these issues. Upgrade to a recent PoDoFo,
or run in the `C' locale.
Where can I get test PDF files?