Most Linux and UNIX OS are already available for 32 bit and 64 bit CPUs. Due to the many CPU and operating systems types, it is almost impossible to provide pre-compiled binaries for all possible variations of supported operating systems.
The Enterprise license of DynaPDF includes the source codes and make files for all supported operating systems. All you need is a properly installed GCC compiler so that you can compile your 64 bit variant by yourself. We guarantee that DynaPDF runs on 64 bit variations of all currently supported operating systems.
Yes. All DynaPDF versions can be replaced without recompiling your applications. Unsupported functions are disabled, but still included in the DLL.
No. ReportToPDF based on DynaPDF 2.0 and since the source codes of the StrStorage.dll are not available, it is not possible to enter a new license key. Therefore, a demo string will be drawn on every page if the dynapdf.dll will be replaced.
The latest version that can be used with ReportToPDF is DynaPDF 2.5.
Yes. DynaPDF offers a content parser that enables searching and changing of existing text strings within an existing PDF file. Strings can be changed or deleted. It is also possible to change the font, font size or font color.
DynaPDF is available for Windows, IBM AIX, HP-UX 11 (64 bit Itanium), Linux for x86/x64, Mac OS X, and Sun Solaris.
DynaPDF is also available for iOS but no pre-compiled binaries are delivered for this platform.
The Windows version is available as 32 bit and 64 bit library. The Mac OS X version is delivered as universal binary for the CPU targets i386, and x86_64.
The license key must be applied with the function SetLicenseKey(). Once the key was passed to the library, the demo string is no longer drawn. Please note that the license key must be applied to every instance separately.
DynaPDF is licensed per developer workplace (except Internet Service Provider (ISPs)). The number of applications, or the number of users who use DynaPDF with the software of the licensee, or whether DynaPDF is used on client or server systems is irrelevant.
Only the number of development workplaces is taken into account. A developer workplace refers to an employee who develops applications on the basis of DynaPDF. One employee can use multiple computers for testing and development purposes, but every employee needs his/her own license.
Internet Service Provider can provide DynaPDF as an extension or separate service for their users. For the license fee, the number of CPUs is taken into account while the numbers of users is irrelevant.
40 bit encryption is definitely not safe. Modern tools can decrypt those files within seconds, independent of the used passwords.
128 or 256 bit encryption is safer as long as both passwords are set and if long passwords were used. Most available decryption tools are only able to decrypt a file by applying a brute force attack. This takes considerable processing time if long and cryptic passwords are used, but it is still not impossible to decrypt those files.
If you need more security, then use additional encryption software.
DynaPDF is no longer available as an ActiveX component. Due to the limited available data types in COM objects, this technology is more suitable for small components. Many features of DynaPDF require a reliable handling of structures which is not possible with Variant data types.
Standard DLLs are more flexible, faster, just as thread-safe, and there is no need to store data in the Registry before they can be used on the target system.
Yes, but PDF pages are printed as an image. Therefore, this kind of printing is more suitable for simple applications. The printer requires enough memory to be able to print images in large resolutions.
When a native print solution will be available is not clear yet.
Yes. DynaPDF 3.0 contains a very powerful rendering engine that is able to render PDF pages or entire PDF files into several popular image formats.
DynaPDF is also delivered with ready viewer components which simplify the integration of a PDF viewer a lot.
The rendering engine does not dependent on the operating system. PDF files can therefore be rendered on all supported operating systems.
Most TrueType and OpenType fonts are too large to be fully embedded in a PDF file. To reduce the amount of data that must be embedded it is possible to remove unused characters.
This technique enables also the usage of very large CJK fonts which require often more than 20 MB disk space. The size of a font subset depends on the number of characters which were used in the document. If only a few characters are used, the resulting font subset can be very small.
When I convert EMF files under Linux/UNIX text strings appear wrong and misplaced. What I am doing wrong?
If the conversion is ok on Windows, then check whether all fonts which are used by the EMF file are available. DynaPDF replaces unavailable fonts with standard fonts so that the EMF file can still be processed but font replacements can cause unpredictable results.
Copy all required fonts into a directory and add this directory to the list of font search paths with AddFontSearchPath().
Note that the Windows TrueType fonts Symbol and and Wingdings are often used for list symbols.
DynaPDF supports TrueType, TrueType Collection, OpenType fonts with TrueType or Postscript outlines, as well as Type1 fonts in the formats PFA and PFB. Metric files are not required for Type1 fonts. CJK character sets and Unicode are not supported in combination with Type1 fonts.
Missing glyphs occur relatively seldom, since DynaPDF checks for missing glyphs and changes the font dynamically if necessary. If one or more glyphs are missing, the font will be changed dynamically to Arial Unicode MS.
Most but not all font issues can be solved in this way. If there is a typo in the font name or if the font is not available, then it is possible that the GDI loads another font as DynaPDF would load. This can lead to problems since both sides use different fonts.
However, such issues can be easily solved by synchronizing the font selection with the GDI. Simply set the flag mfGDIFontSelection with SetMetaConvFlags() and the font selection will be synchronized with the GDI. The overhead for the additional font selection in a temporary device context is not large, therefore the flag can be set by default.
If possible, check the CreateFont() calls in your program and change the font names to valid values if necessary.
Differences can occur if fonts are not embedded in the PDF file. Non-embedded fonts are loaded from the operating system, if available. This is on Windows or Mac OS X, of course, more often possible than on a Linux or Unix system, since fewer fonts are mostly available on these systems.
In order to load fonts on a Linux or Unix system, the font directories must be passed to AddFontSearchPath().
In the past we had problems with certain companies who simply enclosed certain main features of DynaPDF into a wrapper DLL or executable and sold it then as their own product. We don't want to compete with our own software. The software that uses DynaPDF should not be an alternate solution for our own library.
The usage in SDKs where PDF processing is just one part of another main functionality is generally no problem.
For example, DynaPDF is often used in components which output reports, invoices, or comparable documents as PDF. This is of course no problem and should be possible independent of whether the software is distributed as SDK.
If you want to use DynaPDF in a software development kit then please send us an email with a short description about the SDK. If the usage is possible (this is mostly the case) then you'll get an amendment to the license agreement that explicitly permits the usage in your products. Such an amendment is free of charge and applies also to all future versions of DynaPDF.