![\\\"Architecture\\\"](\\\"doc/podofo_architecture.png\\\")
\\nPoDoFo is a library to work with the PDF file format and includes also a few\\ntools. The name comes from the first two letters of PDF (Portable Document\\nFormat).
\\n\\nThe PoDoFo library is a free portable C++ library which includes classes to\\nparse a PDF file and modify its contents into memory. The changes can be\\nwritten back to disk easily. PoDoFo is designed to avoid loading large PDF\\nobjects into memory until they are required and can write large streams\\nimmediately to disk, so it is possible to manipulate quite large files with it.\\nPoDoFo uses and relies on exceptions, so it must be built with them enabled.
\\n\\nBesides PDF parsing and writing PoDoFo includes also very simple classes to\\ncreate your own PDF files. All classes are documented so it is easy to start\\nwriting your own application using PoDoFo.
\\n\\nPoDoFo is primarily useful for applications that wish to do lower level\\nmanipulation of PDF, such as extracting content or merging files. It's also\\nuseful if your application has specific requirements for it's PDF output that\\nmore general output-oriented libraries like Cairo cannot satisfy.\\nCanvas/drawing support is currently very limited in PoDoFo, so for pure output\\ntasks a library like Cairo will be more suitable. PoDoFo cannot render PDF,\\nso you should look at a library like Poppler for that.
\\n\\nSee:
\\n\\n\\n\\nThe PoDoFo tools are simple tools build around the PoDoFo library. These tools\\nare first of all examples on how to use the PoDoFo library in your own\\nprojects. But secondly they offer also features for working with PDF files.\\nMore tools will come with future release and the existing tools will gain more\\nfeatures. The following tools are currently available:
\\n\\nAdditionally there is the external tool PoDoFoBrowser which is not included in\\nthis package, but can be downloaded from the PoDoFo webpage. PoDoFoBrowser is a\\nQt application for browsing and modifying the objects in a PDF file, examining\\nthe structure of PDF files, and manipulating PDF streams. It is very useful if\\nyou want to look on the internal structure of PDF files.
\\n\\nAs of version 0.7 PoDoFo is available for Unix, Mac\\nOS X and Windows platforms.
\\n\\nPoDoFo is available on the internet: podofo.sf.net
\\n\\nTo build PoDoFo lib you need a working toolchain and a c++ compiler as well as\\nthe following libraries:
\\n\\nSee Installation with CMake for a\\nlist of tested platforms and compilers. In general, any reasonably well behaved\\nC++ compiler should work.
\\n\\nA list of known -dev / -devel packages required for various Linux distros is maintained\\nin the required Linux packages appendix.
\\n\\nSee also Using PoDoFo.
\\n\\nRather than using binary packages, you should usually build PoDoFo yourself.\\nThis ensures that it will be built with the same compiler and settings as your\\nprogram. Because most platforms have no consistent C++ ABI or runtime\\nlibraries, this is important to ensure that you get a compatible STL, correct\\nmemory management between podofo and your app, etc.
\\n\\nPoDoFo is built and installed using CMake. The autotools build, Visual Studio\\nproject and XCode project were dropped as maintaining three unrelated and\\nincompatible build systems that are exclusive to three different platforms\\nconsumes a lot of resources which can be spend better on improving PoDoFo\\nitself. Even if you've never used CMake before, you'll find it pretty easy.
\\n\\nUnix users should generate Unix Makefiles with CMake, though it's also possible\\nto produce a KDevelop project. See CMake builds on Linux/UNIX
\\n\\nIf your application or library uses Visual Studio, CMake can be used to\\nbuild a Visual Studio project you can use. Alternately, if you are using\\nMinGW for your existing code, CMake can make you a MinGW makefile to\\nbuild a mingw compatible version of PoDoFo. You must build PoDoFo with\\nthe same compiler as your application. See CMake builds on Windows
\\n\\nMac OS X users will need to use CMake to generate a conventional UNIX build\\nwith Makefiles, or may generate an XCode project with CMake. See the Mac OS X\\n\\tsection below, and the generic instructions for cmake builds
\\n\\n\\nDon't know what STLPort is? Ignore it and skip this section. Packagers should\\nnot enable STLPort.
\\n\\nIf your project uses STLPort rather than your platform/toolset's native STL,\\nyou must configure PoDoFo to use STLPort as well. Use the -DUSE_STLPORT=1\\nargument to configure. Do not enable STLPort for podofo unless you use it in\\nyour project; you will get an incompatible C++ STL leading to link errors,\\nruntime crashes, or other problems.
\\n\\nIt is unnecessary and unwise to build PoDoFo against STLPort on any current\\nmajor platform unless you have a specific reason to do so.
\\n\\nPoDoFo can make limited use of the Boost libraries if they are available.\\nThere is no need to use them, but some things may work more smoothly, and more\\nuse is expected in the future. If PoDoFo is built to use Boost, your\\napplication must also have Boost's headers (boost graph libraries) on its search path. Set\\n-DWANT_BOOST:BOOL=1 to enable Boost support.
\\n\\nPackagers should not currently build PoDoFo with boost support.
\\n\\nPoDoFo has support for builds using CMake on all supported\\nplatforms. The CMake build has been tested on:
\\n\\nPoDoFo is also known to build with Visual C++ 6 using CMake, though it is\\nnot regularly tested by the team so you might need to do some work to use\\na recent svn build.
\\n\\nYou can use the CMake variable CMAKE_BUILD_TYPE to control the type of\\nbuild. The main values supported are DEBUG and RELEASE. The default is\\nDEBUG. Set the build type with the CMake argument:
\\n -DCMAKE_BUILD_TYPE=DEBUG
\\n or
\\n -DCMAKE_BUILD_TYPE=RELEASE
\\nas appropriate.
You can control where the files are installed with `make install' with\\n\\t-DCMAKE_INSTALL_PREFIX=/path/to/install/dir
All instructons below use out-of-tree builds (recommended). To clean up an\\nout-of-tree build, just delete the build directory, as no files are touched\\nwithin the source directory.
\\n\\nOn all Makefile-style builds, set the VERBOSE flag to 1 on the make command\\nline to see all compiler commands etc, eg: make VERBOSE=1
Linux and UNIX users should be able to build PoDoFo by cd'ing into the PoDoFo\\ncheckout or unpacked tarball directory (here assumed to be named \\\"podofo-src\\\")\\nthen running the build commands shown below. The CMake command below will\\ninstall into $HOME/podofo to avoid needing root priveleges for installation,\\nbut you can change the destination to wherever you want or remove the install\\nprefix setting to use the default.
\\n\\nTo build and install:
\\n\\n\\nmkdir ../podofo-build\\ncd ../podofo-build\\ncmake -G \\\"Unix Makefiles\\\" -DCMAKE_INSTALL_PREFIX=\\\"$HOME/podofo\\\" ../podofo-src\\nmake\\nmake install\\n\\n\\n
To see detailed compiler output, use:
\\n\\n\\nmake VERBOSE=1\\n\\n\\n
If you're working on a 64 bit linux that has a /usr/lib64 directory, add\\n-DWANT_LIB64:BOOL=TRUE to the CMake command line.
If you need to specify additional paths to search for libraries, set the\\nCMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH environment variables or set them on\\nthe command line:
\\ncmake -G \\\"Unix Makefiles\\\" ../podofo-src \\\\\\n\\t-DCMAKE_INCLUDE_PATH=/usr/sfw/include \\\\\\n\\t-DCMAKE_LIBRARY_PATH=/usr/sfw/lib\\n\\n\\n
If you wish to generate only a static library or only a shared library, set the\\nPODOFO_BUILD_SHARED and/or PODOFO_BUILD_STATIC flags:
\\ncmake -G \\\"Unix Makefiles\\\" ../podofo-src \\\\\\n\\t-DCMAKE_INCLUDE_PATH=/usr/sfw/include \\\\\\n\\t-DCMAKE_LIBRARY_PATH=/usr/sfw/lib \\\\\\n\\t-DPODOFO_BUILD_SHARED:BOOL=TRUE \\\\\\n\\t-DPODOFO_BUILD_STATIC:BOOL=FALSE\\n\\n\\n
By default, with CMake 2.6.x all supported library types will be built where\\npossible. Only the shared library will be built by default using 2.4.x because\\nof a CMake limitation; you can build a static library instead with\\n-DPODOFO_BUILD_STATIC:BOOL=TRUE, or upgrade to CMake 2.6.x .
Note that the instructions above run an out-of-tree build. CMake does support\\nin-tree builds, but the use of out-of-tree builds is very strongly recommended.
\\n\\nIf your system has gcc 4, PoDoFo will tell gcc to make symbols hidden by\\ndefault using the -fvisibility=hidden flag to gcc. Only symbols explicitly\\nexported by PoDoFo will be exported. You can explicitly enable or disable this\\nbehaviour with the boolean flag:\\n -DPODOFO_USE_VISIBILITY=1 (or 0 for off).\\nEnabling default hidden visibility reduces the PoDoFo binary size dramatically\\nand improves link times. It also helps prevent accidental use of symbols that\\nare not part of PoDoFo's public API. PoDoFo developers will also find this\\nuseful, as it will cause some mistakes to be reported as link errors that would\\notherwise go undetected and break the win32 builds.
Mac OS X users can build PoDoFo using CMake either by generating conventional\\nUNIX Makefiles (the \\\"Unix Makefiles\\\" CMake target) or generating an XCode\\nproject (the \\\"Xcode\\\" target). In either case the following applies.
\\n\\nYou will need freetype and fontconfig. It's possible to omit the use of\\nlibjpeg (see the platform-independent documentation) but by default libjpeg\\nwill also be required. If you have these libraries already (say, from fink\\nor DarwinPorts) you can skip the following section and update the\\nCMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH arguments appropriately.
I'll assume you're installing podofo and any required libraries into $HOME/libs\\n. Adjust to taste, but keep it consistent.
\\n\\nThe easiest way to get any required libraries is to use MacPorts\\nto install the libjpeg, fontconfig, and freetype libraries. Once you've installed MacPorts, just run:
\\n\\n\\n/opt/local/bin/port install fontconfig freetype jpeg tiff lua\\n\\n\\n
MacPorts will automatically build the libraries and their dependencies, installing them in /opt/local.
\\n\\nIf you want to distribute the libraries with your application, all you'll need to do is use install_name_tool to set appropriate relative paths for their linkage and include them in your application bundle - just like you do with any other libraries.
\\n\\nYou should be able to configure and install podofo on Mac OS X using:
\\n\\n\\tcmake -G \\\"Unix Makefiles\\\" \\\\\\n\\t\\t-DWANT_FONTCONFIG:BOOL=TRUE \\\\\\n\\t\\t-DCMAKE_INSTALL_PREFIX=/opt/podofo \\\\\\n\\t\\t-DCMAKE_INCLUDE_PATH=/opt/local/include \\\\\\n\\t\\t-DCMAKE_LIBRARY_PATH=/opt/local/lib \\\\\\n\\t\\t../podofo\\n\\tmake\\n\\tsudo mkdir /opt/podofo\\n\\tsudo chown $USER /opt/podofo\\n\\tmake install\\n\\n\\n
change \\\"Unix Makefiles\\\" to \\\"Xcode\\\" if you want to build an XCode project instead, then\\ninstead of running `make' and `make install' just open the project file and work as normal
\\n\\nFor Homebrew (package manager for Mac OS X) it is quite simple to install podofo. Freetype2 and zlib should be installed on Mac OS X by default.\\n
\\nbrew install fontconfig\\nbrew install libjpeg\\nbrew install libtiff\\ncd ((directory of podofo))\\ncmake -G \\\"Unix Makefiles\\\"\\nmake\\nmake install\\n\\n\\n\\n
PoDoFo requires a couple of other open source libraries to work. At minimum it needs zlib and libjpeg. Additional functionality is enabled if libtiff and/or openssl are available.
\\n\\nBoth MinGW and Visual Studio users should use the standard precompiled zlib dll from zlib.org. There is no need to compile your own.
\\n\\nRemember that you must ship zlib1.dll with your application. During testing it must be in the same directory as the PoDoFo-using executable or the directory containing it must be on your system PATH.
MinGW users can download the latest libjpeg installer from GnuWin32
.\\n\\nFor Visual Studio you will need to build libjpeg with your version of Visual Studio. Download the libjpeg sources from http://www.ijg.org/ and unpack them into a working directory. I'll assume you've used C:\\\\Developer\\\\jpeg. Once the sources are unpacked, start a visual studio command prompt and cd into c:\\\\developer\\\\jpeg then run copy jconfig.vc jconfig.h then nmake /f makefile.vc /a
If you use a DLL build of libjpeg remember that you must ship the DLL with your application. During testing the libjpeg dll must be in the same directory as the PoDoFo-using executable or the directory containing it must be on your system PATH. These requirements do not apply to the (recommended) static library libjpeg.
\\n\\nBuilding PoDoFo on Windows can be done using MinGW (a minimalist gcc-based\\ncompliler environment for Windows) or Visual Studio. Other methods may work but\\nhave not been tested.
\\n\\nCMake 2.6.x is required for Windows. You can download it from\\n cmake.org
.\\n\\nBecause the C++ ABIs of most of the win32 compilers are incompatible, you\\nmust build PoDoFo with the same compiler and version that you will use to build\\nthe programs linked to PoDoFo. Failure to follow this restriction will result\\nin link errors at best, and bizarre runtime failures at worst.
\\n\\nOn Windows, if you are linking against a shared (DLL) build of PoDoFo you\\nMUST define the preprocessor macro USING_SHARED_PODOFO when\\nincluding any podofo headers. Failure to do so will result in link time and/or\\nruntime errors. Similarly, defining it when linking with a static PoDoFo can\\ncause problems.
On Windows, PoDoFo may be built as either a shared or static library.\\nBuilding both is not supported. By default only the shared library will be\\nbuilt. If you want a static library, just disable generation of the shared\\nlibrary with the extra argument to cmake:
\\n\\n\\n\\t-DPODOFO_BUILD_SHARED=FALSE\\n\\n\\n
PoDoFo will generally work correctly if you download pre-built libraries,\\nsuch as those published by the GnuWin32 project, even if they were built with a\\ndifferent compiler. The primary exception is freetype, which should if at all\\npossible be built using your compiler. Freetype provides a VC++ project file\\nand is very easy to build. Make sure to build both the debug multi-threaded and\\nrelease multi-threaded versions.
\\n\\nFor release you should generally build your own copy of these libraries\\nunless there is a well known and high quality pre-built version, like there is\\nfor zlib. If you have built your own libjpeg you can improve PoDoFo's use of\\nit a bit by passing -DJPEG_COMPATIBLE_RUNTIME to CMake to tell\\nPoDoFo it's safe not to use its' workarounds for incompatible runtimes.
Especially on Windows it is also common for custom built libraries to have\\ndifferent names to those you might download as pre-built copies. CMake won't be\\nable to find them if they're called something else unless you tell it. Use\\nthese variables to tell CMake what names to look for a library under:
\\n\\nFor example, a cmake command line might include -DFREETYPE_LIBRARY_NAMES_DEBUG=freetype239MT_D -DFREETYPE_LIBRARY_NAMES_RELEASE=freetype239MT . If you only have the release library, just use -DFREETYPE_LIBRARY_NAMES . Telling CMake which are debug and release libraries helps it ensure you link to the right libraries depending on build type, but that does no good if you don't have a debug library.
\\n\\nTo build PoDoFo with MinGW, you'll naturally need MinGW. The author recommends installing Qt 4 from Trolltech,\\nwhich has a well packaged version of MinGW and is also useful for some PoDoFo tools like PoDoFoBrowser.
\\n\\nOnce MinGW is set up, make sure that the MinGW \\\"bin\\\" directory is on your PATH, and be sure to set\\nCMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH such that\\nCMake can find the headers and .lib files for the libraries PoDoFo requires.\\nThe GnuWin32 library packages from
To configure and build PoDoFo with a default GnuWin32 install and with MinGW already on your PATH:
\\n\\n\\nmd ..\\\\podofo-debug\\ncd ..\\\\podofo-debug\\ncmake -G \\\"MinGW Makefiles\\\" ..\\\\podofo-src -DCMAKE_INCLUDE_PATH=c:\\\\progra~1\\\\gnuwin32\\\\include -DCMAKE_LIBRARY_PATH=c:\\\\progra~1\\\\gnuwin32\\\\lib -DPODOFO_BUILD_SHARED:BOOL=FALSE\\nmingw32-make\\n\\n\\n
It is extremely strongly recommended that you build PoDoFo only as a static\\nlibrary if you are using MinGW by setting the\\n-DPODOFO_BUILD_SHARED:BOOL=FALSE flag to cmake. libstdc++ on MinGW\\nat the time of writing was not a shared library, causing serious issues with\\nmemory allocation and deallocation when C++ objects like\\nstd::string are passed by value across DLL boundaries or are\\notherwise deleted in a different DLL to where they were allocated. Of course,\\nthis will cause you problems if you intend to use PoDoFo across DLL boundaries,\\nbut until libstd++ is made shared on MinGW there's not much to be done. VC++\\ndoes not suffer from this issue.
A Visual Studio build requires that Microsoft Visual Studio be installed.\\nVisual Studio 9 2008 Express Edition is known to work, and is a free download\\nfrom Microsoft. You should get zlib from zlib.org. If you want JPEG support,\\nbuild your own libjpeg from sources or use the version from GnuWin32 (which\\nwill work OK, if a bit slower, despite being built with gcc). It is preferable\\nto build your own copies of freetype, libjpeg and libtiff with your own\\ncompiler and bundle those copies.
\\n\\nYou'll also need CMake 2.6.
\\n\\nIf you're using Visual Studio you really should build your own freetype.\\nWith recent VC++ versions the GnuWin32 version of freetype is unlikely to work\\nreliably. Download the sources from http://download.savannah.gnu.org/releases/freetype/\\n- you want something like ft245.zip . Unpack them and open\\nbuilds\\\\win32\\\\visualc\\\\freetype.sln in VC++, upgrading it if required. Build it\\nin both debug multithreaded and release multithreaded modes. You should now see some\\n.lib files in a subdirectory of the objs\\\\win32\\\\ directory. The following instructions will assume\\nthey're named freetype239MT.lib and\\nfreetype239MT_D.lib and are found in objs\\\\win32\\\\vc2008, so adjust if yours are different.
If you built a debug freetype, you will also need to copy vc90.pdb (assuming you're using VC++ 9, otherwise the name will vary) from objs\\\\debug_mt\\\\vc90.pdb to objs\\\\win32\\\\vc2008\\\\ so that VC++ can find Freetype's debug info.
\\n\\nThe visual studio build of PoDoFo has two stages - first, CMake is used to generate a\\nVisual Studio solution, then the solution is built in VC++. I prefer to create\\na short build.cmd file for the CMake command since on Windows it\\ntends to get rather long. Here's an example that assumes the\\nbuild.cmd file is in an empty directory with\\n..\\\\podofo-src being the relative path to the PoDoFo sources.
\\ndel cmakecache.txt\\nset FTDIR=C:\\\\developer\\\\freetype-2.3.5\\nset FTLIBDIR=C:\\\\developer\\\\freetype-2.3.5\\\\objs\\\\win32\\\\vc2008\\nset JPEGDIR=C:\\\\Developer\\\\jpeg\\nset ZLIBDIR=C:\\\\developer\\\\zlib123-dll\\ncmake -G \\\"Visual Studio 9 2008\\\" ..\\\\podofo-src -DCMAKE_INCLUDE_PATH=\\\"%FTDIR%\\\\include;%JPEGDIR%\\\\include;%JPEGDIR%;%ZLIBDIR%\\\\include\\\" -DCMAKE_LIBRARY_PATH=\\\"%FTLIBDIR%;%FTDIR%\\\\lib;%JPEGDIR%\\\\lib;%JPEGDIR%;%ZLIBDIR%\\\\lib\\\" -DPODOFO_BUILD_SHARED:BOOL=FALSE -DFREETYPE_LIBRARY_NAMES_DEBUG=freetype239MT_D -DFREETYPE_LIBRARY_NAMES_RELEASE=freetype239MT\\n\\n\\n
Run the saved build.cmd from a cmd.exe window. If all goes well, you can open and build the generated podofo.sln in Visual Studio and build it.
Note that CMake should automatically find your Visual Studio install, so you\\nshouldn't need any special settings unless you have an unusual setup or more\\nthan copy of the same version of Visual Studio installed.
\\n\\nYou can download the free Visual C++ Express Edition 9 from Microsoft.
\\n\\nPROBLEMS?\\n\\nIf you have problems, try deleting your build directory then re-running\\nthe commands above after running:
\\n\\n\\nset PATH=%SystemRoot%;%SystemRoot%\\\\SYSTEM32\\n\\n\\n
in the cmd.exe window you are using. If you do this you'll have\\nto copy jpeg62.dll, freetype6.dll, and\\nzlib.dll (names may vary; make sure they're the ones that match\\nthe LIB files you linked to) to the same folder as the .exe you are trying to\\nrun. This should resolve any issues caused by incompatible DLLs with the same\\nnames being present earlier on your PATH - a rather common issue if you have\\nlots of open source software installed. Do this if you get unexplained crashes\\nor errors about missing/mismatched ordinals.
PoDoFo can also be built with NMake. The build procedure is essentially the same\\nas described for MinGW or Visual Studio, but you must use the target name\\n\\\"NMake Makefiles\\\" and run \\\"nmake\\\" after CMake completes. Remember to run everything from\\nwithin a Visual Studio environment shell or to run vcvarsall.bat before running CMake.
\\n\\nWith Visual C++ Express Edition 8, you must also separately run setenv.cmd from the Win32 SDK.\\nThis is not required for Express Edition 9.
\\n\\nA simple example that uses PoDoFo can be found in examples/helloworld . You\\nwill also find the tests and tools shipped with PoDoFo informative when\\nlearning to use the library. Reading the documentation on PdfMemDocument,\\nPdfStreamedDocument, PdfObject and PdfVariant may also be useful.
It is very important to understand that PoDoFo's 0.x's API is not stable from\\nrelease to release. As such, rather than relying on a particular version of\\nPoDoFo being shipped by the OS/distro that you are targeting, consider building\\nand linking to your own private copy of PoDoFo. (Win32 developers will do this\\nanyway). For example, between PoDoFo 0.5.0 and early PoDoFo 0.6.0svn, PdfDocument\\nchanged from being a concrete class to an abstract parent of PdfMemDocument and\\nPdfStreamedDocument, thus breaking code that instantiates PdfDocument .
A good way to handle maintaining your own private copy if you use Subversion\\nfor your project is to use the svn:externals mechanism to automatically\\nreference a specific revision of PoDoFo from podofo svn, or a particular tag .\\nThis permits you to control when you update to a new version and lets you make\\nsure your code is updated for any API changes, without forcing users to go and\\nfind a specific version of PoDoFo. Alternately, you can just check the tree\\ninto your own revision control system and do periodic code drops. Have a look\\nat PoDoFoBrowser for an example of the svn:externals approach.
\\n\\nIf you statically link to podofo, that'll prevent any unexpected problems with\\nlinker paths. Another option on most platforms is to use rpath linking to\\nensure that a specific copy of the podofo library is preferred by the linker.\\nCMake takes care of this automatically if you're using it for your project.
\\n\\nWhen PoDoFo reaches 1.x versions it is expected that API changes will be\\nless frequent. At this point, though, they're an unavoidable part of\\nimproving and completing the library.
\\n\\nIf you are using CMake in your project and you choose to bundle a copy of\\nthe PoDoFo sources, with svn:externals or otherwise, you can quite easily build\\na private copy of PoDoFo as part of your app's normal build process. Have a look\\nat FindLIBPODOFO.cmake from PoDoFoBrowser to see how to do that, or just copy\\nthat file.
\\n\\nPoDoFo's headers are designed to avoid exposing its library dependencies, so\\nyou do not need the headers for Freetype etc on the include path. However, you\\nMUST link your application to podofo's required libraries on most platforms, eg\\non UNIX:
\\n\\n\\n -lpodofo -lfreetype -lfontconfig -ljpeg -lz\\n\\n\\n
is generally appropriate. Win32 users must also ensure that they link to\\ngdi32 and ws_win32.
When working with PoDoFo it is important to remember that the library makes use\\nof exceptions. Your code must be built with exception support and must be\\nexception safe in areas that call PoDoFo. gcc users may not build with\\n-fno-exceptions. If you have non-exception-safe code or code (such as pure C\\ncode) that cannot propagate exceptions your podofo-using code must catch all\\nexceptions before they propagate to such unsafe sections. PoDoFo will throw a\\nPdfError& for PoDoFo-specific exceptions. It may also propagate STL/runtime\\ngenerated exceptions like std::bad_alloc, though it'll never throw them\\ndirectly. PoDoFo cannot be built without exceptions.
\\n\\nMore general information about exception handling is in the FAQ.
\\n\\nSeveral preprocessor defines are used inside PoDoFo. This section tries to\\n document all of them. These defines are set automatically by the CMake build\\n system, so usually you do not have to worry about them.
\\n\\n| Define | \\nMeaning | \\n
DEBUG | \\n Indicates a debug build of PoDoFo. | \\n
PODOFO_EXTRA_CHECKS | \\n Should we do lots of extra (expensive) sanity checking? You should not\\ndefine this on production builds because of the runtime cost and because it\\nmight cause the library to abort() if it notices something nasty.\\nIt may also change the size of some objects, and is thus not binary\\ncompatible.\\n | \\n
PODOFO_IS_LITTLE_ENDIAN | \\n This define is set on all little endian\\n system and required on these systems for PoDoFo to work properly. | \\n
PODOFO_IS_BIG_ENDIAN | \\n This define is set on all big endian\\n system and required on these systems for PoDoFo to work properly. | \\n
PODOFO_MULTI_THREAD | \\n Will compile PoDoFo with threading support, e.g. mutex that lock\\n global variables. | \\n
PODOFO_VERBOSE_DEBUG | \\n This will cause PoDoFo to write even more debug output to the commandline. | \\n
HAVE_BOOST | \\n If defined PoDoFo is compiled with Boost support. | \\n
PODOFO_HAVE_JPEG_LIB | \\n If defined PoDoFo will use libJpeg to read and decode JPEG images. | \\n
PODOFO_HAVE_TIFF_LIB | \\n If defined PoDoFo will use libTiff to read and decode TIFF images. | \\n
PODOFO_HAVE_LUA | \\n If defined PoDoFoImpose will be built with Lua support for plan files. | \\n
PoDoFo is structured into two libraries podofo-base\\n and podofo-doc, where most users want to use podofo-doc which\\n includes all the PoDoFo features and dependends on the podofo-base\\n library. \\n
\\n\\n\\nIf you only need basic PDF editing features and are not afraid of working with\\nthe object in a PDF file directly (see PdfObject), podofo-base is the\\nright choice for you. It has only a few dependencies (zlib and libjpeg for\\ncompression). Contrary, podofo-doc provides you with a much richer and\\neasier to use interface, but has some more dependencies to handle fonts and\\nimages. The image below shows the dependencies of each of the two\\nlibraries.\\n
\\n\\n\\n
If you have questions on PoDoFo or bug reports, feature requests you can email\\nour mailinglist <podofo-users@lists.sf.net>. Sign up details are available\\non the podofo support page.
\\n\\nThe library is licensed under the LGPL (i.e. you may even use the shared\\nlibrary in closed sourced applications). The tests and tools which are\\nincluded in PoDoFo are licensed under the GPL. See the files COPYING and\\nCOPYING.LIB for details. More detailed explanations are in the FAQ on the\\nwebsite, but the licenses have the final say.
\\n\\nLinux distros love to name their packages in various weird ways. Here are commands to install the required -dev or -devel packages for PoDoFo for various distros. Please send additions for reasonably recent distros to the PoDoFo mailing list.
\\n\\n