# PoDoFo FAQ

General

- What platforms are supported by PoDoFo?
- Can I use PoDoFo in my commercial application?
- What language is PoDoFo written in?
- Does PoDoFo offer a stable API or ABI
- Does PoDoFo have a mailing list?
- My question isn't answered here. Where do I go next?"

Other Languages

- My program is written in C. Can I use PoDoFo?
- Is there a C wrapper for PoDoFo?
- I'm a Java developer. Can I use PoDoFo?
- Are any other languages supported?

Troubleshooting

- Sometimes my program crashes in a call to PoDoFo and produces a traceback including a call to `std::terminate()`. Why?
- Why does my program crash with a SIGABRT (Signal #6) in a call to PoDoFo?
- PoDoFo creates invalid PDF files because , is used in floats instead of .?

## General

What platforms are supported by PoDoFo?

PoDoFo has been tested on Linux, Mac OS X and Windows. It is developed in a way 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 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.

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 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 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.

My question isn't answered here. Where do I go next?

Your best bet is to email the podofo-users mailing list.

## Other Languages

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:

- 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.

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.

Are any other languages supported?

No. Python bindings would be a fun Boost::Python project, though.

## Troubleshooting

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 that causes the crash if possible, and full information about your platform (OS/distro and version, what the CPU is, etc).

PoDoFo creates invalid PDF files because , is used in floats instead of .?

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.
PoDoFo uses the standard C++ library functions to write floating point numbers and these are dependent on the current locale setting of your system. You have to make sure to the an English locale so that PoDoFo will create correct PDF files in any situation.

`setlocale( LC_NUMERIC, "C" )`